demystifying oauth 2.0

57
Karl McGuinness Senior Director, Identity @ Okta Demystifying OAuth

Upload: karl-mcguinness

Post on 16-Apr-2017

2.048 views

Category:

Technology


3 download

TRANSCRIPT

Page 1: Demystifying OAuth 2.0

Karl McGuinnessSenior Director, Identity @ Okta

Demystifying OAuth

Page 2: Demystifying OAuth 2.0

Why OAuth?

Breaking down OAuth 2.0

Pseudo-Authentication

OpenID Connect

Agenda

Security & The Enterprise

Page 3: Demystifying OAuth 2.0

Direct AuthenticationPassword anti-pattern

3

GET /index.html HTTP/1.1 Host: www.example.comAuthorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Page 4: Demystifying OAuth 2.0

Federated Identity

4

Identity Provider (IdP)

Service Provider(SP)

End User

Trust

Obtains Assertion Provides Assertion

Page 5: Demystifying OAuth 2.0

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

Page 6: Demystifying OAuth 2.0

SAML 2.0OASIS Standard, 15 March 2005

6

Authentication Request Protocol

Assertion

Page 7: Demystifying OAuth 2.0

SAML 2.0 Authentication Request Protocol

7

Page 8: Demystifying OAuth 2.0

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>

Page 9: Demystifying OAuth 2.0

SAML = Web SSO

9

Page 10: Demystifying OAuth 2.0

What’s Changed since 2005?

10

Page 11: Demystifying OAuth 2.0

Modern and Native Applications

11

Page 12: Demystifying OAuth 2.0

Connected Experiences across Devices

12

Page 13: Demystifying OAuth 2.0

Simple Web APIsGET POST PUT DELETE

13

Page 14: Demystifying OAuth 2.0

API Economy

14

Page 15: Demystifying OAuth 2.0

Delegated Authorization ProblemHow can a user authorize an app to access protected data on their behalf?

15

Page 16: Demystifying OAuth 2.0

Have you ever seen one of these?

16

Page 17: Demystifying OAuth 2.0

17

Page 18: Demystifying OAuth 2.0

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

Page 19: Demystifying OAuth 2.0

Hotel Key Cards but for Apps

19

Page 20: Demystifying OAuth 2.0

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

Page 21: Demystifying OAuth 2.0

OAuth 2.0

21

• Scopes & Consent• Actors• Clients• Tokens• Authorization Server• Flows

Page 22: Demystifying OAuth 2.0

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

Page 23: Demystifying OAuth 2.0

Capturing User ConsentAuthorization Grant (Trust of First Use)

23

Page 24: Demystifying OAuth 2.0

Actors

ResourceServer (RS)

AuthorizationServer (AS)

Resource Owner (RO)

Client

Delegates

Obtains Token

Uses Token

Page 25: Demystifying OAuth 2.0

Actors

ResourceServer (RS)

AuthorizationServer (AS)

Resource Owner (RO)

Client

Delegates

Obtains Token

Uses Token

Page 26: Demystifying OAuth 2.0

Clients

26

Public(Client Identification)

Confidential(Client Authentication)

Page 27: Demystifying OAuth 2.0

ClientsClient Registration is the DMV of OAuth

Page 28: Demystifying OAuth 2.0

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!

Page 29: Demystifying OAuth 2.0

Authorization ServerAuthorization Grant Types are Extensible

29

Authorize Endpoint (/oauth2/authorize)

Token Endpoint(/oauth2/token)

Authorization Server

Authorization Grant

Refresh Token

Access Token

Page 30: Demystifying OAuth 2.0

Token State ManagementDeveloper Friction

30

Page 31: Demystifying OAuth 2.0

Flow Channels

ResourceServer (RS)

AuthorizationServer (AS)

Resource Owner (RO)

Client

Delegates

Obtains Token

Uses Token

Back Channel

FrontChannel

Page 32: Demystifying OAuth 2.0

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)

Page 33: Demystifying OAuth 2.0

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

Page 34: Demystifying OAuth 2.0

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

Page 35: Demystifying OAuth 2.0

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

Page 36: Demystifying OAuth 2.0

Making Protected Resource Requests

curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" \https://www.googleapis.com/gmail/v1/users/1444587525/messages

36

Page 37: Demystifying OAuth 2.0

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)

Page 38: Demystifying OAuth 2.0

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)

Page 39: Demystifying OAuth 2.0

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

Page 40: Demystifying OAuth 2.0

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

Page 41: Demystifying OAuth 2.0

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

Page 42: Demystifying OAuth 2.0

42

Authorization Framework?

Page 43: Demystifying OAuth 2.0

Like WS-Security Security

43

Page 44: Demystifying OAuth 2.0

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

Page 45: Demystifying OAuth 2.0

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

Page 46: Demystifying OAuth 2.0

46

Not an AuthenticationProtocol?

Page 47: Demystifying OAuth 2.0

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

Page 48: Demystifying OAuth 2.0

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

Page 49: Demystifying OAuth 2.0

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

Page 50: Demystifying OAuth 2.0

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

Page 51: Demystifying OAuth 2.0

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

Page 52: Demystifying OAuth 2.0

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

Page 53: Demystifying OAuth 2.0

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

Page 54: Demystifying OAuth 2.0

Modern OAuth-based Protocols

OAuth 2.0

OpenID Connect

UMANAPPS

Page 55: Demystifying OAuth 2.0

Q&A

Page 56: Demystifying OAuth 2.0

Rate this sessionin the mobile app!

Page 57: Demystifying OAuth 2.0

Thank You.