Demystifying OAuth 2.0
-
Upload
karl-mcguinness -
Category
Technology
-
view
2.049 -
download
3
Transcript of Demystifying OAuth 2.0
Karl McGuinnessSenior Director, Identity @ Okta
Demystifying OAuth
Why OAuth?
Breaking down OAuth 2.0
Pseudo-Authentication
OpenID Connect
Agenda
Security & The Enterprise
Direct AuthenticationPassword anti-pattern
3
GET /index.html HTTP/1.1 Host: www.example.comAuthorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Federated Identity
4
Identity Provider (IdP)
Service Provider(SP)
End User
Trust
Obtains Assertion Provides Assertion
Identity as Claims
A claim is a statement or assertion that a certain fact applies to something or somebody
• First Name = ‘Karl’• Age > 21• Okta Employee
Issued by an Authority for a Subject (e.g. user, device, etc.)• Can self-asserted such as Facebook profile or issuer asserted such as Okta Organization• Explicit trust relationship with an issuer• Are subject to verification
5
SAML 2.0OASIS Standard, 15 March 2005
6
Authentication Request Protocol
Assertion
SAML 2.0 Authentication Request Protocol
7
SAML 2.0 Assertion
8
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="b07b804c-‐7c29-‐ea16-‐7300-‐4f3d6f7928ac" Version="2.0" IssueInstant="2004-‐12-‐05T09:22:05"
<Issuer>https://example.okta.com<Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature><Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-‐format:unspecified">[email protected]
</NameID><SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"></SubjectConfirmation>
</Subject><Conditions NotBefore="2004-‐12-‐05T09:17:05" NotOnOrAfter="2004-‐12-‐05T09:27:05">
<AudienceRestriction><saml:Audience>https://sp.example.com/saml2/sso</saml:Audience>
</AudienceRestriction></Conditions><AuthnStatement AuthnInstant="2004-‐12-‐05T09:22:00" SessionIndex="b07b804c-‐7c29-‐ea16-‐7300-‐4f3d6f7928ac">
<AuthnContext><AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef></AuthnContext>
</AuthnStatement><AttributeStatement>
<Attribute Name=“displayName”><AttributeValue>Karl McGuinness</AttributeValue>
</Attribute></AttributeStatement>
</Assertion>
SAML = Web SSO
9
What’s Changed since 2005?
10
Modern and Native Applications
11
Connected Experiences across Devices
12
Simple Web APIsGET POST PUT DELETE
13
API Economy
14
Delegated Authorization ProblemHow can a user authorize an app to access protected data on their behalf?
15
Have you ever seen one of these?
16
17
OAuth 2.0Web-scale delegated authorization framework for REST/APIs
• Enables apps to obtain limited access (scopes) to a user’s data without giving away a user’s password
• Decouples authentication from authorization
• Supports multiple use cases addressing different client capabilities and deployment models• Server-to-server apps• Browser-based apps• Mobile/Native apps• Consoles/TVs
Protecting APIsSince
October 2012
Hotel Key Cards but for Apps
19
OAuth Simplified
App requests authorization from User
20
1
User authorizes App and delivers proof2
App presents proof of authorization to server to get a Token3
Token is restricted to only access what the User authorized for the specific App
4
OAuth 2.0
21
• Scopes & Consent• Actors• Clients• Tokens• Authorization Server• Flows
Scopes
• Additive bundles of permissions asked by client when requesting a token
• Decouples authorization policy decisions from enforcement
22
Scopes to Deny
Scopes to Allow
Capturing User ConsentAuthorization Grant (Trust of First Use)
23
Actors
ResourceServer (RS)
AuthorizationServer (AS)
Resource Owner (RO)
Client
Delegates
Obtains Token
Uses Token
Actors
ResourceServer (RS)
AuthorizationServer (AS)
Resource Owner (RO)
Client
Delegates
Obtains Token
Uses Token
Clients
26
Public(Client Identification)
Confidential(Client Authentication)
ClientsClient Registration is the DMV of OAuth
Tokens
28
• Short- lived token used by Client to access Resource Server (API)
• No client authentication required (Public Clients)
• Optimized for scale and performance
• Usually can’t be revoked
Access Token (Required)
• Long- lived token that is used by Client to obtain new access tokens from Author ization Server
• Usually requires Confidential Clients with authentication
• Forces client to rotate secrets
• Can be revoked
Refresh Token (Optional)
OAuth doesn’t define the format of a token!
Authorization ServerAuthorization Grant Types are Extensible
29
Authorize Endpoint (/oauth2/authorize)
Token Endpoint(/oauth2/token)
Authorization Server
Authorization Grant
Refresh Token
Access Token
Token State ManagementDeveloper Friction
30
Flow Channels
ResourceServer (RS)
AuthorizationServer (AS)
Resource Owner (RO)
Client
Delegates
Obtains Token
Uses Token
Back Channel
FrontChannel
Front Channel FlowAuthorize via User Agent
ResourceServer (RS)
AuthorizationServer (AS)
42
3
1 Resource Owner starts flow to delegate access to protected resource
1
Client
2 Client sends authorization request with desired scopes via browser redirect to Authorize Endpoint on Authorization Server
3 User authenticates and consents to Delegated Access (Grant)
4 Authorization Code Grant orAccess Token is returned to Clientvia browser redirect
Resource Owner (RO)
Authorization Request
GET https://accounts.google.com/o/oauth2/auth?Scope=gmail.insert gmail.send&redirect_uri=https://app.example.com/oauth2/callback&response_type=code&client_id=812741506391&state=af0ifjsldkj
HTTP/1.1 302 FoundLocation: https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7&state=af0ifjsldkj
Request
Response
Note: Parameters are not URL-encoded for example purposes
Back Channel FlowExchange Grants for Tokens
ResourceServer (RS)
AuthorizationServer (AS)
1
Client
2 Client accesses protected resource with Access Token
Resource Owner (RS)
2
Client sends access token request to Token Endpoint on Authorization Server with confidential client credentials or public client id
Exchanges Authorization Code Grantfor Access Token and optionally Refresh Token
1
Token RequestPOST /oauth2/v3/token HTTP/1.1
Host: www.googleapis.com
Content-‐Type: application/x-‐www-‐form-‐urlencoded
code=MsCeLvIaQm6bTrgtp7&
client_id=812741506391&client_secret={client_secret}&
redirect_uri=https://app.example.com/oauth2/callback&
grant_type=authorization_code
{
"access_token" : "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
}
Request
Response
Note: Parameters are not URL-encoded for example purposes
Making Protected Resource Requests
curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" \https://www.googleapis.com/gmail/v1/users/1444587525/messages
36
OAuth 2.0 Grant Types (Flows)
37
• Optimized for browser-only Public Clients
• Access token returned directly from author ization request (Front-channel only)
• Does not support refresh tokens
• Assumes Resource Owner and Public Client are on the same device
• Most vulnerable to secur ity threats
Implicit (2 Legged)
• Front channel f low used by Client to obtain author ization code grant
• Back channel f low used by Client to exchange author ization code grant for access token and optionallyrefresh token
• Assumes Resource Owner and Client are on separate devices
• Most secure f low as tokens never passes through user-agent
Authorization Code (3 Legged)
• Optimized for server-only Confidential Clients acting on behalf of itself or a user
• Back-channel only f low to obtain an access token using the Client’scredentials
• Supports shared secrets or assertions as Clientcredentials signed with either symmetr ic or asymmetr ic keys
Client Credential (2 Legged)
OAuth 2.0 Grant Types (Flows)
38
• Legacy grant type for native username/password apps such as desktop apps
• Username/password is author ization grant to obtain access token fromAuthor ization Server
• Does not support refresh tokens
• Assumes Resource Owner and Public Client or on the same device
Resource Owner Password
• Allows Author ization Server to trust author ization grants from third party such as SAML IdP (Federation)
• Assertion is used to obtain access token with token request
• Does not support refresh tokens
Assertion (2 Legged)
• Optimized for devices that do not have access to web-browsers
• User code is returned from author ization request that must be redeemed by visit ing a URL on a device with a browser to author ize
• Back channel f low used by Client to poll for author ization approval for access token and optionallyrefresh token
Device (Non-Standard)
Common OAuth 2.0 Security Issues
• Too many inputs that need validation• Token hijacking with CSRF
• Always use CSRF token with state parameter to ensure OAuth flow integrity
• Leaking authorization codes or tokens through redirects• Always whitelist redirect URIs and ensure proper URI validations
• Token hijacking by switching clients • Bind the same client to authorization grants and token requests
• Leaking client secrets• Unbounded & Bearer Tokens
• See draft specification of OAuth Proof-of-Possession Token Extension
39
Key Enterprise OAuth 2.0 Use Cases
• Decouples authorization policy decisions from enforcement• Enables the right blend of fine & coarse
grained authorization• Replaces traditional Web Access
management (WAM) Policies• Restrict & revoke which apps can access
specific APIs• Ensure only managed and/or complaint
devices can access specific APIs• Deep integration with identity
deprovisioning workflow to revoke all tokens for a user and device
• Federation with an IdP
40
OAuth 2.0 Facts
• Not backward compatible with OAuth 1.0• Replaces signatures with HTTPS for
all communication
• Interoperability issues exists as its not a protocol but rather an authorization framework
• OAuth 2.0 is not an authentication protocol
• OAuth 2.0 alone says absolutely nothing about the user
41
42
Authorization Framework?
Like WS-Security Security
43
Authorization FrameworkReturn of Complexity through Extensions
44
OAuth 2 FrameworkRFC 6749
Assertion FrameworkRFC 7521
Token IntrospectionRFC 7662
Token RevocationRFC 7009
Dynamic Client RegistrationRFC 7591
JSONRFC 7159
JSON Web Token Bearer AssertionRFC 7523
Proof Key for Code Exchange (PKCE)RFC 7636
Simple Authentication and Security Layer (SASL)RFC 7628
Token ExchangeDraft
SAML 2.0 Bearer AssertionRFC 7522
Proof of PossessionDraft
JSON Web Token (JWT)RFC 7519
JSON Web Signature (JWS)RFC 7515
JSON Web Encryption (JWE) RFC 7516
JSON Web Key (JWK)RFC 7517
Bearer Token RFC 6750
Why all the complexity again?
• Enterprise use cases such as federation• Interoperable tokens that can be signed and encrypted• Proof-of-Possession tokens that can’t be replayed• Embedded user agents with unsecure cross-app communication
channels• Intermediates can capture resource owner credentials, grants, and tokens
• Bindings for non-HTTP transports and legacy protocols such as LDAP or IMAP as well as constrained devices (IoT)
45
46
Not an AuthenticationProtocol?
OAuth 2.0 as Pseudo-AuthenticationAs made famous by Facebook Connect and Twitter
Client accessing a https://api.example.com/me resource with an access token is not authenticating the userAccess tokens just prove the Clientwas authorized, are opaque, and intended to only be consumed by the Resource Server
• Who is the user (claims)?• When did the user authenticate?
• Does the user still have an active or expired session?
• How did the user authenticate? • Just password or password +
second factor
47
OpenID ConnectOAuth 2.0 + Facebook Connect + SAML 2.0 (good parts)
• Extends OAuth 2.0 with new signed id_token for the Client and UserInfo endpoint to fetch user attributes
• Provides a standard set of scopes and claims for identities• profile• email• address• phone
• Built-in registration, discovery & metadata for dynamic federations• Bring Your Own Identity (BYOI)
• Supports high assurance levels and key SAML use cases (enterprise)
48
OpenID Connect Authorization Request
GET https://accounts.google.com/o/oauth2/auth?scope=openid email&redirect_uri=https://app.example.com/oauth2/callback&response_type=code&client_id=812741506391&state=af0ifjsldkj
HTTP/1.1 302 FoundLocation: https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7&state=af0ifjsldkj
Request
Response
Note: Parameters are not URL-encoded for example purposes
OpenID Connect Token RequestPOST /oauth2/v3/token HTTP/1.1
Host: www.googleapis.com
Content-‐Type: application/x-‐www-‐form-‐urlencoded
code=MsCeLvIaQm6bTrgtp7&
client_id=812741506391&client_secret={client_secret}&
redirect_uri=https://app.example.com/oauth2/callback&
grant_type=authorization_code
{
"access_token" : "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ…",
}
Request
Response
Note: Parameters are not URL-encoded for example purposes
JSON Web Token (JWT)base64url(Header) + “.” + base64url(Claims) + “.” + base64url(Signature)
eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUub2t0YS5jb20iLCJzdWIiOiIwMHVncmVuTWVxdllsYTRIVzBnMyIsImF1ZCI6IncyNTVIRVdpU1U0QXVOeEVqZWlqIiwiaWF0IjoxNDQ2MzA1MjgyLCJleHAiOjE0NDYzMDg4ODIsImFtciI6WyJwd2QiXSwiYXV0aF90aW1lIjoxNDQ2MzA1MjgyLCJlbWFpbCI6ImthcmxAZXhhbXBsZS5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZX0.XcNXs4C7DqpR22LLti777AMMVCxM7FjEPKZQnd-AS_Cc6R54wuQ5EApuY6GVFCkIlnfbNmYSbHMkO4H-L3uoeXVOPQmcqhNPDLLEChj00jQwZDjhPD9uBoNwGyiZ9_YKwsRpzbg9NEeY8xEwXJFIdk6SRktTFrVNHAOIhEQsgm8
51
{"alg": "RS256"
}
{"iss": "https://example.okta.com","sub": "00ugrenMeqvYla4HW0g3","aud": "w255HEWiSU4AuNxEjeij","iat": 1446305282,"exp": 1446308882,"amr": ["pwd"
],"auth_time": 1446305282,"email": "[email protected]","email_verified": true
}
Header Claims
Signature
Header
Claims
OpenID Connect is built on OAuth 2.0
Validate (JWT)ID Token
Token Endpoint
Authorization Endpoint
/.well-known/webfinger/openid-configuration
Client Registration Endpoint
JWKS Endpoint
Check Session iFrame
End Session Endpoint
UserInfo Endpoint
OAuth 2.0 Authorization Server &OpenID Connect Provider (OP)
OAuth 2.0 Resource Server
API Endpoints
Client(Relying Party)
1
2
3
5
64
1 Discover OIDC Metadata
2 Get JWT signature keys and optionally dynamically register Client
3 Perform OAuth flow to obtain id_token and access token
4 Validate JWT id_token
5 Get additional user attributes with access token
6 Validate session and/or logout
Summary
• OAuth 2.0 is an authorization framework for delegated access to APIs• Clients request scopes that Resources Owners authorize (consent)• Authorization grants are exchanged for an access token and optionally refresh token• Multiple flows to address varying Client capabilities and authorization scenarios• Use JSON Web Tokens (JWT) for structured tokens between Authorization Server and
Resource Server
• OAuth 2,0 has a very large security surface area• Use a secure toolkit and remember to validate all inputs!
• OAuth 2.0 is not an authentication protocol• OpenID Connect extends OAuth 2.0 for authentication scenarios
“SAML with curly-braces”
53
Modern OAuth-based Protocols
OAuth 2.0
OpenID Connect
UMANAPPS
Q&A
Rate this sessionin the mobile app!
Thank You.