What the Heck is OAuth and OpenID Connect - DOSUG 2018

OAuth is not an API or a service: it is an open standard for authorization and any developer can implement it. OAuth is a standard that applications can use to provide client applications with “secure delegated access”. OAuth works over HTTPS and authorizes devices, APIs, servers, and applications with access tokens rather than credentials, which we will go over in depth below. OpenID Connect (OIDC) is built on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the user and to obtain their basic profile information.

This session covers how OAuth/OIDC works, when to use them, and frameworks/services that simplify authentication.

Companion blog post: https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth

Transcript

1. © Okta and/or its affiliates. All rights reserved. Okta Confidential Matt Raible | @mraible What the Heck is OAuth and OIDC? February 6, 2018
2. Blogger on raibledesigns.com Web Developer and Java Champion Father, Skier, Mountain Biker, Whitewater Rafter Open Source Connoisseur Who is Matt Raible? Bus Lover Okta Developer Advocate
6. developer.okta.com
7. Authentication Standards
8. What about You? Java, .NET, Python, or Node.js? Have you ever written authentication from scratch? Have you implemented OAuth or OIDC? Have you heard of Okta? Auth0? Why are you here?
9. Originally created by Karl McGuinness @jankytweet
10. OAuth 2.0 Overview
11. An open standard for authorization; anyone can implement it Provides “secure delegated access” to client applications Works over HTTPS and authorizes: Devices APIs Servers Applications … with access tokens rather than credentials What is OAuth?
12. Direct Authentication GET /index.html HTTP/1.1 Host: www.example.com Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
13. Federated Identity Identity Provider (IdP) Service Provider (SP) End User Trust Obtains Assertion Provides Assertion
14. How Federated Identity Works
15. SAML 2.0 OASIS Standard, 15 March 2005 Authentication Request Protocol Assertion
16. SAML 2.0 Authentication Request Protocol
17. SAML 2.0 Assertion <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"> matt@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>Matt Raible</AttributeValue> </Attribute> </AttributeStatement> </Assertion>
18. SAML = Web SSO
20. SOA
21. What’s Changed Since 2005?
22. Cloud-native applications are dynamic and public!
23. Modern and native applications
24. Connected experiences across devices
25. Simple Web APIs GET POST PUT DELETE
26. API Economy
27. API-driven Initiatives Custom Web and Mobile Apps B2B Partner Integration Developer Ecosystem Shared Services Platform for the Enterprise
28. 2017: The Year of the API Economy
29. Delegated Authorization Problem How can a user authorize an app to access protected data on their behalf?
30. Have you ever seen one of these?
31. © Okta and/or its affiliates. All rights reserved. Okta Confidential
32. OAuth 2.0 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 Web-scale delegated authorization framework for REST/APIs Protecting APIs Since October 2012
33. Modern Applications Browser App Server App Web API Web API Web API Native App Web App
34. Hotel Key Cards, but for Apps
35. Hotel Key Cards, but for Apps OAuth Authorization Server Resource (API) Access Token
36. OAuth Simplified App requests authorization from User 1 User authorizes App and delivers proof 2 App presents proof of authorization to server to get a Token 3 Token is restricted to only access what the User authorized for the specific App 4
37. OAuth 2.0 Actors Clients Scopes & Consent Tokens Authorization Server Flows
38. Authorization
 Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token Resource
 Server (RS) Actors
39. Authorization
 Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token Resource
 Server (RS) Actors
40. Clients Public (Client Identification) Confidential
 (Client Authentication)
41. Clients Client Registration is the DMV of OAuth
42. Scopes Additive bundles of permissions asked by client when requesting a token Decouples authorization policy decisions from enforcement Who owns the data? End user or the target service Who gets to specify the authorization policy? End user or application owner Scopes to Deny Scopes to Allow
43. Capturing User Consent Authorization Grant (Trust of First Use)
44. Tokens • Short-lived token used by Client to access Resource Server (API) • Opaque to the Client • No client authentication required (Public Clients) • Optimized for scale and performance • Revocation is dependent on implementation Access Token (Required) • Long-lived token that is used by Client to obtain new access tokens from Authorization Server • Usually requires Confidential Clients with authentication • Forces client to rotate secrets • Can usually be revoked Refresh Token (Optional) OAuth doesn’t define the format of a token!
45. Access Token Types Self-contained tokens Protected, time-limited data structure agreed upon between Authorization Server and Resource Server that contains metadata and claims about the identity of the user or client over the wire. Resource Server can validate the token locally by checking the signature, expected issuer name and expected audience or scope. Commonly implemented as a signed JSON Web Tokens (JWT) Reference tokens (aka opaque tokens) Infeasible-to-guess (secure-random) identifier for a token issued and stored by the OAuth 2.0 Authorization Server Resource Server must send the identifier via back-channel to the OAuth 2.0 Authorization Server’s token introspection endpoint to determine if the token is valid and obtain claims/scopes
46. JSON Web Token (JWT) base64url(Header) + “.” + base64url(Claims) + “.” + base64url(Signature) eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2 V4YW1wbGUub2t0YS5jb20iLCJzdWIiOiIwMHVncmVuT WVxdllsYTRIVzBnMyIsImF1ZCI6IncyNTVIRVdpU1U0 QXVOeEVqZWlqIiwiaWF0IjoxNDQ2MzA1MjgyLCJleHA iOjE0NDYzMDg4ODIsImFtciI6WyJwd2QiXSwiYXV0aF 90aW1lIjoxNDQ2MzA1MjgyLCJlbWFpbCI6ImthcmxAZ XhhbXBsZS5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1 ZX0.XcNXs4C7DqpR22LLti777AMMVCxM7FjEPKZQnd- AS_Cc6R54wuQ5EApuY6GVFCkIlnfbNmYSbHMkO4H- L3uoeXVOPQmcqhNPDLLEChj00jQwZDjhPD9uBoNwGyi Z9_YKwsRpzbg9NEeY8xEwXJFIdk6SRktTFrVNHAOIhE Qsgm8 { "alg": "RS256”
 "kid": "123456789" } { "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
47. Token Issuer and Audience Audience Issuer
48. Token Issuer and Audience Resource Server (RS) audience: api.example.com Authorization Server (AS) issuer: org.okta.com Resource Server (RS) audience: foo.example.com Resource Domain Client trust trust issuer (iss): org.okta.com audience (aud): api.example.com
49. Authorization Server Authorize Endpoint (/ oauth2/authorize) Token Endpoint (/oauth2/token) Authorization Server Authorization Grant Refresh Token Access Token Introspection Endpoint (/ oauth2/introspect) Revocation Endpoint (/ oauth2/revoke)
50. © Okta and/or its affiliates. All rights reserved. Okta Confidential Token State Management Developer Friction 50
51. Flow Channels Resource
 Server (RS) Authorization
 Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token Back Channel Front Channel
52. Front Channel Flow Authorize via User Agent Resource
 Server (RS) Authorization
 Server (AS) 4 2 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 or Access Token is returned to Client via browser redirect Resource Owner (RO)
53. 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 Found
 Location: https://app.example.com/oauth2/callback?
 code=MsCeLvIaQm6bTrgtp7&
 state=af0ifjsldkj Request Response Note: Parameters are not URL-encoded for example purposes
54. Back Channel Flow Exchange Grants for Tokens Resource
 Server (RS) Authorization
 Server (AS) 1 Client 2 Client accesses protected resource with Access Token Resource Owner (RO) 2 Client exchanges Authorization Code Grant with token endpoint on Authorization Server for an Access Token and optionally Refresh Token 1
55. Token Request POST /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 Note: Parameters are not URL-encoded for example purposes
56. Token Response { "access_token": "2YotnFZFEjr1zCsicMWpAA", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA" }
57. Making Protected Resource Requests curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" \ https://www.googleapis.com/gmail/v1/users/1444587525/messages
58. OAuth 2.0 Grant Types (Flows) • Optimized for browser-only Public Clients • Access token returned directly from authorization request (Front-channel only) • Does not support refresh tokens • Assumes Resource Owner and Public Client are on the same device • Most vulnerable to security threats Implicit (2 Legged) • Front channel flow used by Client to obtain authorization code grant • Back channel flow used by Client to exchange authorization code grant for access token and optionally refresh token • Assumes Resource Owner and Client are on separate devices • Most secure flow 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 flow to obtain an access token using the Client’s credentials • Supports shared secrets or assertions as Client credentials signed with either symmetric or asymmetric keys Client Credential
59. OAuth 2.0 Grant Types (Flows) • Legacy grant type for native username/password apps such as desktop apps • Username/password is authorization grant to obtain access token from Authorization Server • Does not support refresh tokens • Assumes Resource Owner and Public Client or on the same device Resource Owner Password • Allows Authorization Server to trust authorization 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 • Optimized for devices that do not have access to web- browsers • User code is returned from authorization request that must be redeemed by visiting a URL on a device with a browser to authorize • Back channel flow used by Client to poll for authorization approval for access token and optionally refresh token Device
60. OAuth Flows Six different flows Necessary because of: How you get consent from client? Who is making consent? Adds a lot of complexity to OAuth When people ask if you support OAuth, are they asking for all six? Image: Ian Sane, Spring Runoff
 https://www.flickr.com/photos/31246066@N04/4620052369
61. 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
62. 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 and 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
63. OAuth 2.0 Facts Not backward compatible with OAuth 1.0 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
64. © Okta and/or its affiliates. All rights reserved. Okta Confidential 64 Authorization Framework?
65. Like WS-Security Security
66. Authorization Framework Return of Complexity through Extensions OAuth 2 Framework RFC 6749 Assertion Framework RFC 7521 Token Introspection RFC 7662 Token Revocation RFC 7009 Dynamic Client Registration RFC 7591 JSON RFC 7159 JSON Web Token Bearer Assertion RFC 7523 Proof Key for Code Exchange (PKCE) RFC 7636 Token Exchange Draft SAML 2.0 Bearer Assertion RFC 7522 Proof of Possession Draft 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
67. 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 Bindings for non-HTTP transports and legacy protocols such as LDAP or IMAP as well as constrained devices (IoT) 67
68. © Okta and/or its affiliates. All rights reserved. Okta Confidential 68 Not an Authentication Protocol?
69. OAuth 2.0 as Pseudo-Authentication Client accessing a https:// api.example.com/me resource with an access token is not authenticating the user Access tokens just prove the Client was 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 As made famous by Facebook Connect and Twitter
70. OpenID Connect OpenID Connect
71. OpenID Connect 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) OAuth 2.0 + Facebook Connect + SAML 2.0 (good parts)
72. 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 Found
 Location: https://app.example.com/oauth2/callback?
 code=MsCeLvIaQm6bTrgtp7&
 state=af0ifjsldkj Request Response Note: Parameters are not URL-encoded for example purposes
73. Token Request POST /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 Note: Parameters are not URL-encoded for example purposes
74. Token Response { "access_token": "2YotnFZFEjr1zCsicMWpAA", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA", "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ..." }
75. Validate ID Token Token Endpoint Authorization Endpoint /.well-known/
 openid-configuration JWKS Endpoint UserInfo Endpoint OAuth 2.0 Authorization Server & OpenID Connect Provider (OP) OAuth 2.0 Resource Server Client (Relying Party) 1 3 2 5 4 1 Discover OpenID Provider Metadata 2 Perform OAuth flow to obtain a ID token and/or access token 3 Get JSON Web Key Set (JWKS) for signature keys 4 Validate ID token
 (JSON Web Token) 5 Get additional user attributes with access token from UserInfo endpoint OpenID Connect
76. Which grant type is right for you? Authorization
 Code Implicit Authorization
 Code Client Credentials OAuth 2.0 Only
77. Implicit Flow (SPA) Authenticate via User Agent 1 User starts flow by visiting Single Page App Client with User Agent 2 Client sends authentication request with openid scope via browser redirect to Authorize Endpoint on Authorization Server 3 User authenticates and consents to Client to access user’s identity 4 ID Token and optionally Access Token for SPA app is returned to Client via browser redirect 4 2 3 1 User SPA
 (Client) Resource
 Server (RS) /UserInfo Authorization
 Server (AS) 5 Client optionally fetches additional claims with Access Token from UserInfo endpoint 5
78. Authorization Code Flow (Web) Authenticate via User Agent 1 User starts flow by visiting Web App Client with User Agent 2 Client sends authentication request with openid scope via browser redirect to Authorize Endpoint on Authorization Server 3 User authenticates and consents to Client to access user’s identity 4 Authorization Code Grant and optionally ID Token for Web App is returned to Client via browser redirect 4 2 3 1 User Web App
 (Client) Resource
 Server (RS) /UserInfo Authorization
 Server (AS)
79. Authorization Code Flow (Web) Exchange Grant for Tokens 1b 1a User Web App
 (Client) Resource
 Server (RS) /UserInfo Authorization
 Server (AS) 2 2 Client optionally fetches additional claims with Access Token from UserInfo endpoint Client authenticates & exchanges Authorization Code Grant with token endpoint on Authorization Server for an ID Token, Access Token and optionally Refresh Token 1
80. Session Best Practices ID Tokens should be used to create a session for a traditional web application or single-page application Use subject claim (sub) as stable identifier for the user account Session cookies should be protected with HTTPOnly flag to prevent JavaScript access Avoid using ID Tokens as a stateless “session token” for Single Page Apps API is not the audience of the token ID Tokens can be large in size and often contain PII or other sensitive data ID Token lifetime is not your app’s session lifetime
81. Authorization Code Flow (Native) Authenticate via User Agent 1 User starts flow by launching Native App Client 2 Client launches User Agent and sends authentication request with openid scope and PKCE code challenge via browser redirect to Authorize Endpoint on Authorization Server 3 User authenticates and consents to Client to access user’s identity 4 Authorization Code Grant and optionally ID Token for Web App is returned to Client via browser redirect and User Agent is closed 4 2 3 1 User Native App
 (Client) Resource
 Server (RS) /UserInfo Authorization
 Server (AS)
82. Authorization Code Flow (Native) Exchange Grant for Tokens 1b 1a User Native App
 (Client) Resource
 Server (RS) /UserInfo Authorization
 Server (AS) 2 2 Client optionally fetches additional claims with Access Token from UserInfo endpoint Client exchanges Authorization Code Grant and PKCE code verifier with token endpoint on Authorization Server for an ID Token, Access Token and optionally Refresh Token 1
83. Native App Best Practices Do not use an embedded web views for authenticating users! App (or 3rd party library/script) can directly obtain the user’s credentials which goes against OAuth’s raison d'être Users can’t reuse their existing session with their IdP (SSO) increasing friction for sign-in/sign-up IdPs can’t implement new authentication methods Do not store client secrets in apps that are distributed via App Stores! Use PKCE (RFC 7636) to protect authorization code from interception Follow guidelines outlined in OAuth 2.0 for Native Apps Best Current Practice
 https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12 302 Found
 Location: app://redirect
84. Just Use AppAuth! https://appauth.io Implements OAuth 2.0 for Native Apps Best Current Practice
85. Sign-In Widget and JS Auth SDK 85 Open-source embeddable widget for end-to-end sign-in flow with MFA and account recovery Returns an ID Token for authenticated user Supports social authentication providers Built-on common JS Auth SDK Open source: https://github.com/okta/okta-signin- widget
86. Sign-In Widget and JS Auth SDK Wraps Okta authentication and session management APIs in JS callbacks for custom UX Implements custom web messaging OAuth 2.0 response mode (okta-post- message) for single page applications with hidden iframe Open source: https://github.com/okta/okta-auth-js authClient.signIn({ username: 'some-username', password: 'some-password' }) .then(function(transaction) { if (transaction.status === 'SUCCESS') { authClient.session.setCookieAndRedirect(transaction.sessionToken); } });
87. Specifications Implemented by Okta OpenID Connect Core 1.0 (spec) OpenID Provider Metadata (spec) OAuth 2.0 (RFC 6749) OAuth 2.0 Bearer Token Usage (RFC 6750) OAuth 2.0 Multiple Response Types (spec) OAuth 2.0 Form Post Response Mode (spec) OAuth 2.0 Token Revocation (RFC 7009) OAuth 2.0 Token Introspection (RFC 7662) Proof Key for Code Exchange by OAuth Public Clients (RFC 7636)
88. OAuth and OIDC Demos github.com/oktadeveloper
89. Google OAuth Client Library ScribeJava Spring Security OAuth Nimbus OAuth SDK List of client and server libraries for many languages: https://oauth.net/code/ OAuth and OIDC Libraries
90. ORY Hydra https://github.com/ory/hydra Apereo CAS https://github.com/apereo/cas Keycloak https://github.com/keycloak/keycloak JHipster UAA https://jhipster.github.io/using-uaa/ Open Source OAuth and OIDC Servers
91. OAuth Specification oauth.net OAuth 2.0 Servers oauth.com Additional Resources
92. developer.okta.com/blog
93. Questions? Keep in touch! raibledesigns.com @mraible Presentations speakerdeck.com/mraible Code github.com/oktadeveloper