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">karl@example.com

</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":  "karl@example.com","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.