oauth in the real world featuring webshell

© 2014 CA. All rights reserved.

OAuth In The Real World How today’s authorization experts get maximum value from OAuth

K. Scott Morrison

Senior Vice President and Distinguished Engineer

April 2014

Mehdi Medjaoul

Co-Founder & Executive Director of Webshell

2 © 2014 CA. All rights reserved.

Housekeeping

Layer 7

@layer7

layer7.com/blogs

layer7.com

Chat questions into the sidebar or use hashtag: #L7webinar

Webshell.io

@Webshell_


Today’s Talk

Why OAuth is more than just another security token

The basic OAuth architecture

What’s your grant type?

Token revocation and the implications for scaling

Managing dangerous windows of opportunity

Where should tokens reside?

Scopes, privileges and consent

OAuth facades over existing IAM systems

OAuth integration with legacy HTML login pages


Basic OAuth 2.0

Client

Authorization Server

Resource Server

Resource Owner

Acquire Tokens

Use Access Token


A Fundamental Shift Is Occurring In Identity and Access Control

The Old Enterprise The New Modern Enterprise

This is the secret to achieve scale and agile federation


What’s Your Grant Type?

Do you need to authenticate the end

user? No

Yes

Client Credentials Grant Type

Asking the right questions will lead to the right answer


What’s Your Grant Type (cont.)?

Do you control the user’s credentials?

Yes

No

Password Grant Type


What’s Your Grant Type (cont.)?

Can clients keep secrets?

Yes

No

Authorization Code Grant Type

Implicit Flow, response_type=token

These are usually JavaScript clients. Note that you can’t secure clients here!


What Kind Of Scale Are We Talking?

1000s of validated transactions per second

Millions of active sessions


Token Validation and the Question of Revocation

Will you ever need to revoke access tokens?

No

Yes

Easy street

Tough Road

Tokens have a lifetime. But will you ever need to cut this short?

Tokens can be signed and self-contained (incl. expiration time,

scope, and other attributes).

Tokens need a central validation service


No Revocation – The Simple Case Very simple distributed auth architecture Authorization Server (AS) keeps refresh tokens

locally for issuance of new access tokens

Resource Server (RS) validates access tokens according to trust model

Need signed tokens

Kind of like SAML

Enterprise Network

Informal, API-driven

integrations

Firewall

Mobile Devices

Clouds, Webapps, etc


Key DB

Directory

Protected Resource Servers

Trust

Refresh tokens only. Low transaction rate (eg: 10 mins for each active session)


Revocation – The Much Harder Scenario More Complex distributed architecture Authorization Server (AS) keeps refresh and

access tokens

Resource Server (RS) validates access tokens live (various options for this)

Scalable DB needed

Security model for token storage

Enterprise Network

Firewall

Mobile Devices


Key DB Directory


Validates

Admin

This is where scale and reliability become important requirements.


Managing Dangerous Windows of Opportunity

Time

t=10 minutes time-to-live for access token

No Revocation

Token hijack

10 min Time

t=10 minutes time-to-live for access token

With Revocation

Token hijack

4 min 5 min 10 min

Validation cache time out

Revoke tokens


Where Should The Tokens Reside?

Enterprise Network

Firewall 1


Directory Validates

Admin

Key DB

Firewall 2


DB Inside Secure Zone Tokens do not reside in DMZ

Remember: Bearer tokens are dangerous!

RDBMS vs NoSQL

Token maintenance issues

Authorization Server (AS) manages access and refresh tokens using JDBC/ODBC or noSQL

Resource Server (RS) validates access tokens using JDBC/ODBC or noSQL

Case 1: Just use a DB


Where Should The Tokens Reside (cont.)?

Enterprise Network

Firewall 1


Directory

Admin

Key DB Firewall 2

DB Inside Secure Zone Tokens do not reside in DMZ

Authorization Server (AS) accesses access and refresh tokens using simple CRUD APIs

Resource Server (RS) validates access tokens using validation API or OpenID Connect UserInfo

Case 2: API server fronting DB

Validate

Key CRUD



Scopes and Privileges Scopes are critical in OAuth

– But developers too often overlook their power

Attach scope to an access token based on user privileges

– Same endpoint, but different capabilities

The OpenID Connect UserInfo endpoint is like this

We are seeing scope being differentiated based on how an access token was acquired

– Eg: If the access token derives from an immediate authentication event, it is of higher relative “value” than if it comes from a refresh

Continuous authentication is an important trend in security

Scope is the key to integrating risk-based evaluation, step-up authentication, idle time mgmt, privileged action mgmt, etc

The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued.


Consent This remains very black and white

– It is the responsibility of the OAuth (and API) provider to seek consent expression and reflect this in the scopes granted to a session

– You still can’t choose what you agree to

But watch this space

– This is the new frontier for OAuth and related technologies

Do you agree to let application foo:

Records on your behalf?

Create Retrieve Update Delete

No Yes


What We Are Seeing Everywhere: Proxy Model - OAuth Facades over legacy IAM Infrastructure

Simple, drop-in virtual or hardware gateway

Acts as both Authorization Server (AS) and Resource Server (RS)

Advanced security on all APIs

Enterprise Network


integrations

Mobile Devices


Protected Resources

SecureSpan Gateway as

AS IAM System

SecureSpan Gateway

Protecting RS

Token can encapsulate legacy sessionID or gateway can

manage mapping

AS is Mapping to Internal Security Models/Tokens

➠ Simple Username/passwd

➠ Kerberos

➠ X.509v3 certificates

➠ SAML, etc


What We Are Seeing Everywhere: OAuth Integration With Existing Web Authentication

Enterprise Network


integrations

Mobile Devices


Protected Resources not

shown for clarity

SecureSpan Gateway as

AS

Leverage Existing Auth Pages ➠ Redirect to web authentication server

➠ Authentication user, redirect back to OAuth authorization server

➠ Validate returned “legacy” session

➠ Issue standard access and refresh tokens (or encapsulate)

Legacy Directory

Web Auth Page

Validate session

Redirects

This is interesting because it decouples authentication and consent


Summary

You can tell OAuth is mature because its boundaries are being pushed.

But there is still considerable misunderstanding about how to use OAuth effectively.

Scalability and reliability remain difficult

We highly recommend you use proven solutions rather than trying to cobble together a solution.

@medjawii

OAuth.io@medjawii

APIscene.com

Are you getting the maximum from OAuth?

OAuth.io@medjawii

Identity provider

Identity consumer

(Application)User

OAuth.io@medjawii

OAuth.io@medjawii

OAuth provider

OAuth consumer(Application)

User

OAuth.io@medjawii

OAuth.io@medjawii

OAuth provider


User

The business value data is concentrated mainly on the provider and the consumer

OAuth.io@medjawii

OAuth provider


User

OAuth enables to concentrate the business

value data on the provider side.

OAuth.io@medjawii

The tale of 2 OAuth...

OAuth.io@medjawii

OAuth 1.0/1.a- Released in October 2007

- Revised in June 2009 (Revision A)

- Hard to implement with signatures, no expiration of tokens, no control the level

of access requested.

Some implementations have tried to get around these problems, which causes interoperability issues

OAuth.io@medjawii

OAuth 2.0- Non-backward compatible alternative.

- Several drafts from January 2010 and October 2012 where published as RFC 6749

- Facebook and many others implemented it when not final

- OAuth 2.0 is more flexible, wide range of non-interoperable implementations

- less secure than OAuth 1.0, relying on SSL connections rather than signatures to

protect the user’s access token,

- Easier to install when developing clients

OAuth.io@medjawii

http://tools.ietf.org/html/rfc6749

The tale of 2 OAuth...

OAuth.io@medjawii

The tale of too many OAuth...

OAuth.io@medjawii

10 OAuth implementations you can’t guess…

that differ from RFC6949

OAuth.io@medjawii

Facebook :

Refresh_token grant_type: "refresh_token" => grant_type: "fb_exchange_token"refresh_token: "{{refresh_token}}" => fb_exchange_token: "{{refresh_token}}"

scope “notation”: friends_actions.music, friends_actions.video

Separator is a “,” instead of “%20“

OAuth.io@medjawii

Deezer

client_id -> app_id=...

scope -> perms=email,read_friendlists...

state=... [non documented]

response_type=code [useless]

“Facebook is the standard”

OAuth.io@medjawii

Google :

More parameters options for the authorization form:

access_type: to choose to send a refresh_token or notapproval_prompt to force the popup even if we are already connectedlogin_hint to select an account or prefill the email addressinclude_granted_scopes to add more authorizations “incremental authorization”

OAuth.io@medjawii

Foursquare :

- Some OAuth libraries expect to pass the OAuth token as access_token instead of oauth_token, since this is the expectation created by Facebook, at odds with earlier versions of the OAuth spec. We may add support for both parameter names, depending on feedback, but for now know that this may come up.

- No scope.

OAuth.io@medjawii

Salesforce :Added custom authorization parameters:immediate: whether the user should be prompted for login and approvaldisplay: template web, mobile, popuplogin_hint: to prefill an emailprompt: prompt the user for reauthorization or reapproval

the authorization returns custom fields: - “instance_url”: the api url binded to a resource server, this is the only way to receive the domain - a signature: can be used to verify the identity URL was not modified (id & date signed with a private key) - issued_at instead of expires_in : salesforce prefers to give the issued time instead of the expiration duration - id_token: to support openid

UX for creating an app (4 not-so-easy to find mouseclicks between login & the app creation form)

OAuth.io@medjawii

VK:

Added authorizations parameters v: API version

The authorization returns the user id, that is needed to call the api relative to the authorized user (there is no /me/..., /self/... or so)

Instead of access_token: xxx/user/me?access_token=xxx

You haveaccess_token: xxxuser_id: yyy/user/yyy?access_token=xxx

OAuth.io@medjawii

23ANDME:

scope “notation”: profile:write profile:read

OAuth.io@medjawii

Tencent weibo:

Authorization parameters : chinese language only

oauth_version=2.a (useless parameter)

Extra : Chinese/English documentation for OAuth1.0 but Chinese documentation only for OAuth2.0

OAuth.io@medjawii

This was just non exhaustive.

OAuth.io@medjawii

API calls Authorization

api.provider.com/path/action?access_token=TOKEN

api.provider.com/path/action?oauth_token=TOKEN

api.provider.com/path/action?token=TOKEN

Authorization HTTP header: Bearer TOKEN

Authorization HTTP Header: OAuth TOKEN

OAuth.io@medjawii

Scopescope=email%20publish

scope=email,publish

scope=email;publish

scope=email:publish

scope=email|publish

scope=read_only or scope=read_write

OAuth.io@medjawii

The "state" param

● inexistent (dailymotion, eventbrite...) so you have to put it in the callback

● undocumented (wordpress, deezer...)

● impossible (angelist.co) “fixed callback url”

OAuth.io@medjawii

What you should not tell yourself about OAuth

- “OAuth is not so hard to understand”- “It will be easier to it in this non-standard way”

- “Developers just have to read our documentation”

OAuth.io@medjawii

April fool: Introducing OAuth 3:0

- “0 token” paradigm- No more secret key, everything public

The huge majority did not understand...

OAuth.io@medjawii


- “OAuth is not so hard to understand”

- “It will be easier to it in this non-standard way”


OAuth.io@medjawii

Even if you are right,

3rd party developers will be lost…

because of others providers already

did it wrong before you

OAuth.io@medjawii


- “OAuth is not so hard to understand”

- “It will be easier to it in this non-standard way”


OAuth.io@medjawii

“In a design perspective,

documentation is a bug, not a feature”It is the most important but the last place to find information

OAuth.io@medjawii

OAuth.io@medjawii

Devil’s in the details.

OAuth.io@medjawii

OAuth.io

100+ providers unified and simplified

OAuth.io@medjawii

OAuth.io@medjawii

To retrieve you token

OAuth.io@medjawii

- Register on oauth.io- Click on the OAuth provider you want in the list- Share you credentials - Click on “try me“

That’s it, you have your token.90seconds after signup.

OAuth.io@medjawii

And for generating the pop-

up?

OAuth.io@medjawii

OAuth.initialize("OAUTHIO_KEY");

OAuth.popup('facebook', function(err) {

if (err) {

// do something with error

}

OAuth.io@medjawii


OAuth.popup('twitter', function(err) {

if (err) {


}

OAuth.io@medjawii


OAuth.popup('salesforce', function(err) {

if (err) {


}

OAuth.io@medjawii


OAuth.popup('yourcompany', function(err) {

if (err) {


}

OAuth.io@medjawii

And for deeper APIs calls?

OAuth.io@medjawii

OAuth.popup('twitter', function(err, res) {

if (err) {


}

res.get('/1.1/account/verify_credentials.json')

.done(function(data) {

alert('Hello ' + data.name)

})

})

OAuth.io@medjawii

OAuth.popup('twitter', function(err, res) {

if (err) {


}

res.get('/1.1/account/verify_credentials.json')

.done(function(data) {

alert('Hello ' + data.name)

})

})

No need to call your own server and to sign your API request and send it

back

No more access token management, it’s now completely abstracted

It feels lighter right?

For web and mobile

Open source : oauthd for on premises implementation to consume your own oauth

https://github.com/oauth-io/oauthdEasy contributions process,

with a small JSON to fill on github

Questions?

[email protected]

@KScottMorrison

slideshare.net/CAinc

linkedin.com/KScottMorrison

ca.com

K. Scott Morrison

Distinguished Engineer

23 Copyright © 2014 CA. All rights reserved.

© Copyright CA 2013. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. No unauthorized use, copying or distribution permitted.

THIS PRESENTATION IS FOR YOUR INFORMATIONAL PURPOSES ONLY. CA assumes no responsibility for the accuracy or completeness of the information. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENT “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. In no event will CA be liable for any loss or damage, direct or indirect, in connection with this presentation, including, without limitation, lost profits, lost investment, business interruption, goodwill, or lost data, even if CA is expressly advised of the possibility of such damages.

Certain information in this presentation may outline CA’s general product direction. This presentation shall not serve to (i) affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (ii) amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this presentation remain at CA’s sole discretion.

Notwithstanding anything in this presentation to the contrary, upon the general availability of any future CA product release referenced in this presentation, CA may make such release available (i) for sale to new licensees of such product; and (ii) in the form of a regularly scheduled major product release. Such releases may be made available to current licensees of such product who are current subscribers to CA maintenance and support on a when and if-available basis.

notices

oauth in the real world featuring webshell

Technology