The document discusses OAuth's significance in modern security architecture, emphasizing its evolution from OAuth 1.0 to 2.0, alongside the various grant types and token management strategies. It highlights challenges around scalability, token revocation, and proper placement of tokens within secure environments, as well as the importance of scopes and consent in the authorization flow. With practical examples and recommendations, the presentation aims to clarify misconceptions and promote effective usage of OAuth in integrating identity and access control.

1. © 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. 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_

3. 3 © 2014 CA. All rights reserved.
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

4. 4 © 2014 CA. All rights reserved.
Basic OAuth 2.0
Client
Authorization
Server
Resource
Server
Resource
Owner
Acquire
Tokens
Use Access
Token

5. 5 © 2014 CA. All rights reserved.
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

6. 6 © 2014 CA. All rights reserved.
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

7. 7 © 2014 CA. All rights reserved.
What’s Your Grant Type (cont.)?
Do you control the
user’s credentials?
Yes
No
Password
Grant Type

8. 8 © 2014 CA. All rights reserved.
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!

9. 9 © 2014 CA. All rights reserved.
What Kind Of Scale Are We Talking?
1000s of validated
transactions per second
Millions of active sessions

10. 10 © 2014 CA. All rights reserved.
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

11. 11 © 2014 CA. All rights reserved.
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
Authorization
Server
Key DB
Directory
Protected
Resource
Servers
Trust
Refresh tokens only. Low
transaction rate (eg: 10 mins
for each active session)

12. 12 © 2014 CA. All rights reserved.
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
Authorization
Server
Key DB
Directory
Protected
Resource
Servers
Validates
Admin
This is where scale and reliability
become important requirements.

13. 13 © 2014 CA. All rights reserved.
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

14. 14 © 2014 CA. All rights reserved.
Where Should The Tokens Reside?
Enterprise
Network
Firewall 1
Authorization
Server
Directory
Validates
Admin
Key DB
Firewall 2
Protected
Resource
Servers
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

15. 15 © 2014 CA. All rights reserved.
Where Should The Tokens Reside (cont.)?
Enterprise
Network
Firewall 1
Authorization
Server
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
Protected
Resource
Servers

16. 16 © 2014 CA. All rights reserved.
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.

17. 17 © 2014 CA. All rights reserved.
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

18. 18 © 2014 CA. All rights reserved.
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
Informal,
API-driven
integrations
Mobile
Devices
Clouds,
Webapps, etc
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

19. 19 © 2014 CA. All rights reserved.
What We Are Seeing Everywhere:
OAuth Integration With Existing Web Authentication
Enterprise
Network
Informal,
API-driven
integrations
Mobile
Devices
Clouds,
Webapps, etc
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

20. 20 © 2014 CA. All rights reserved.
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.

21. @medjawii
OAuth.io@medjawii
APIscene.com

22. Are you getting the
maximum from OAuth?
OAuth.io@medjawii

23. Identity
provider
Identity
consumer
(Application)
User
OAuth.io@medjawii

24. OAuth.io@medjawii
OAuth
provider
OAuth
consumer
(Application)
User

26. OAuth.io@medjawii

27. OAuth.io@medjawii
OAuth
provider
OAuth
consumer
(Application)
User

28. The business value
data is concentrated
mainly on the provider
and the consumer
OAuth.io@medjawii
OAuth
provider
OAuth
consumer
(Application)
User

29. OAuth enables to
concentrate the business
value data on the provider
side.
OAuth.io@medjawii

30. The tale of 2 OAuth...
OAuth.io@medjawii

31. 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

32. 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

33. The tale of 2 OAuth...
OAuth.io@medjawii

34. The tale of too many OAuth...
OAuth.io@medjawii

35. 10 OAuth implementations
you can’t guess…
that differ from RFC6949
OAuth.io@medjawii

36. 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

37. Deezer
client_id -> app_id=...
scope -> perms=email,read_friendlists...
state=... [non documented]
response_type=code [useless]
“Facebook is the standard”
OAuth.io@medjawii

38. Google :
More parameters options for the authorization form:
access_type: to choose to send a refresh_token or not
approval_prompt to force the popup even if we are already connected
login_hint to select an account or prefill the email address
include_granted_scopes to add more authorizations “incremental
authorization”
OAuth.io@medjawii

39. 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

40. Salesforce :
Added custom authorization parameters:
immediate: whether the user should be prompted for login and approval
display: template web, mobile, popup
login_hint: to prefill an email
prompt: 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

41. 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 have
access_token: xxx
user_id: yyy
/user/yyy?access_token=xxx
OAuth.io@medjawii

42. 23ANDME:
scope “notation”: profile:write profile:read
OAuth.io@medjawii

43. 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

44. This was just non exhaustive.
OAuth.io@medjawii

45. 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

46. Scope
scope=email%20publish
scope=email,publish
scope=email;publish
scope=email:publish
scope=email|publish
scope=read_only or scope=read_write
OAuth.io@medjawii

47. 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

48. 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

49. April fool: Introducing OAuth 3:0
- “0 token” paradigm
- No more secret key, everything public
The huge majority did not understand...
OAuth.io@medjawii

50. 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

51. Even if you are right,
3rd party developers will be lost…
because of others providers already
did it wrong before you
OAuth.io@medjawii

52. 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

53. “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

55. OAuth.io@medjawii
Devil’s in the details.

56. OAuth.io@medjawii
OAuth.io

57. 100+ providers unified
and simplified
OAuth.io@medjawii

58. OAuth.io@medjawii
To retrieve you token

59. 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.

60. OAuth.io@medjawii
And for generating the pop-
up?

61. OAuth.io@medjawii
OAuth.initialize("OAUTHIO_KEY");
OAuth.popup('facebook', function(err) {
if (err) {
// do something with error
}

62. OAuth.io@medjawii
OAuth.initialize("OAUTHIO_KEY");
OAuth.popup('twitter', function(err) {
if (err) {
// do something with error
}

63. OAuth.io@medjawii
OAuth.initialize("OAUTHIO_KEY");
OAuth.popup('salesforce', function(err) {
if (err) {
// do something with error
}

64. OAuth.io@medjawii
OAuth.initialize("OAUTHIO_KEY");
OAuth.popup('yourcompany', function(err) {
if (err) {
// do something with error
}

65. OAuth.io@medjawii
And for deeper APIs calls?

66. OAuth.io@medjawii
OAuth.popup('twitter', function(err, res) {
if (err) {
// do something with error
}
res.get('/1.1/account/verify_credentials.json')
.done(function(data) {
alert('Hello ' + data.name)
})
})

67. OAuth.io@medjawii
OAuth.popup('twitter', function(err, res) {
if (err) {
// do something with error
}
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?

68. For web and mobile

69. Open source : oauthd for on premises
implementation to consume your own oauth
https://github.com/oauth-io/oauthd
Easy contributions process,
with a small JSON to fill on github

70. Questions?

71. Scott.Morrison@ca.com
@KScottMorrison
slideshare.net/CAinc
linkedin.com/KScottMorrison
ca.com
K. Scott Morrison
Distinguished Engineer

72. 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