DevFest2024-Decoding OAuth and OpenID Connect for Mobile Developers

If you’ve not read RFC 8252 or found it overwhelming, fear not. I aim to break down this specification, distilling it into digestible key concepts that underscore your everyday work. RFC 8252 provides essential guidelines for implementing OAuth 2.0 in native applications, focusing on the unique security and usability challenges these apps face compared to their web counterparts. The presentation is designed to demystify the intricate processes of OAuth, translating technical jargon into practical knowledge specifically for mobile developers. I will introduce the fundamentals of OAuth, highlighting its importance in the architecture of mobile applications. This will set the stage for a deeper exploration of the various types of tokens used in OAuth. We will explore ID Tokens, Access Tokens, and Refresh Tokens. We’ll delve into their distinct functions, examine their payloads and claims, and understand how they collectively ensure a secure application experience. I will address the differences among various token types, the nuances of authentication versus authorization, the nature of different grant types, and the methods for validating tokens. By the end of this session, attendees will have a solid grasp of RFC 8252’s guidelines and a better understanding of how to effectively implement OAuth 2.0 in their native applications.
Speaker: Chrystian Vieyra Cortes

Transcript

1. Decoding OAuth and OpenID Connect for Mobile Developers CHRYSTIAN VIEYRA CORTÉS SENIOR ENGINEERING MANAGER Xfinity 1
2. Xfinity 2
3. Overview 1. Background 2. Jargon 3. Tokens 4. OAuth 2.0 5. Resources 6. Conclusion 3
4. 1. Background 4
5. Give Me Your Password 5 https://blog.codinghorror.com/please-give-us-your-email-password/ 1. Background
6. Give Me Your Password • 2013 • LinkedIn and Yelp encouraged users to share their email usernames and passwords to find contacts. • Unrestricted access! 6 https://www.adamfowlerit.com/2013/06/linkedin-securityinformation-risks-with-excha nge/ 1. Background
7. Internet Engineering Task Force (IETF) 7 https://www.ietf.org/logo/ 1. Background • Establishes and promotes internet standards • Open, international community • Publishes technical documents called Requests for Comments (RFC) • Key standards: TCP/IP, HTTP, OAuth
8. OpenID Foundation 8 https://openid.net/foundation/ 1. Background • Non-profit organization focused on standardizing the OpenID technologies • OpenID • Open standard to allow users to authenticate to websites • OpenID Connect • Identity layer on top of OAuth 2.0
9. OAuth1.0 (Open Authorization) 9 1. Background • 2006 - Conceived by group from Twitter, Verisign, Ma.gnolia, etc. • 2010 - Formalized as an IETF standard: RFC 5849. • Token-based • Three-legged flow: 1. Client obtains a request token from service provider. 2. User authorizes access; redirected back to client with a verifier. 3. Client exchanges the request token and verifier for an access token. https://datatracker.ietf.org/doc/html/rfc5849
10. OAuth1.0 (Open Authorization) 10 1. Background • Lacked support for non-browser apps • Required cryptographic signing of each request • Complex protocol 🡪 increased risk of implementation errors • Lacked refresh tokens https://datatracker.ietf.org/doc/html/rfc5849
11. OAuth 2.0 (Open Authorization) 11 1. Background • 2012 – Released as standard under title RFC 6749 • Protocol allows for issuing access tokens to third party clients • Uses HTTPS for security instead of application signatures • Has multiple flows (grants) • Introduces refresh/discard token mechanisms
12. 2. Jargon 12
13. OAuth Actors • Client: the application • Resource owner: the user • Resource server: the API • Authorization server: server issuing access tokens 13 2. Jargon
14. Authentication vs. Authorization • Authentication: Who you are • OpenID Connect • Authorization: What you can do • OAuth 2.0 14 2. Jargon
15. Authentication: OpenID Connect • Identity layer on top of the OAuth 2.0 protocol • Allows clients to verify the identity of the user • Utilizes JWT for identity tokens • End user: User that wants to prove their identity • Relying Party: Application that wants to verify the user’s identity • OpenID Provider (IDP): Service that authenticates the user’s identity 15 2. Jargon
16. Clients - Confidential or Public • Confidential Clients: Server-side applications running on a secure server • Can securely hold sensitive data such as client_secret • Public Clients: Applications installed on a user’s device 16 2. Jargon
17. Client Secret and Client ID • Client ID: A publicly exposed string which is used by the authorization server to identify the application (client) • Client Secret: A confidential key known only to the client and the authorization server used to authenticate the identity of the client when an access token is requested 17 2. Jargon
18. 3. Tokens 18
19. All About JSON Web Tokens • Three parts • Header: Token type and signing algorithm. • Payload: Claims data, such as user information and permissions. • Signature: Verifies the token’s authenticity and integrity • Encoded in Base64 format • Commonly pronounced as J W T or Jot • Open standard (RFC 7519) 19 3. Tokens
20. All About JSON Web Tokens Header • Includes type and algorithm used Payload • Claims, properties and other information Signature • To verify authenticity of the token 20 3. Tokens
21. ID Token – OpenID Connect • JWT format • Issued during the authentication process • Not for Authorization – should not be sent to an API • Contains claims or fields that provide information about the user 21 3. Tokens
22. Access Token – OAuth 2.0 • No specific format, but commonly in JWT • Used for authorization • Bearer tokens • Short lifespans--lasting hours/days • Scopes within Access Tokens define the resources and operations an application is authorized to access. 22 3. Tokens
23. Refresh Token – OAuth 2.0 • No format, but they are commonly in JWT • Long-lived • Obtains new access tokens without prompting user for credentials again • Token should be stored securely on the keychain or encrypted shared preferences. If lost, it could lead to unlimited access to resources. 23 3. Tokens
24. 24 3. Tokens https://cloudentity.com/developers/b asics/oauth-grant-types/refresh-tok en-flow/
25. Token Revocation • Invalidates issued access or refresh token • RFC 7009 • Client sends a request to the server's revoke endpoint to initiate token revocation • The token to be revoked is included in the body of this HTTP POST request 25 3. Tokens
26. Token Revocation 26 3. Tokens
27. jwt.io • JWT debugger • Decoding of JWTs • Token verification 27 3. Tokens
28. 4. OAuth 2.0 28
29. OAuth 2.0 Grant Types Grant Type: The way an application can get an access token • Implicit Grant: Obtains tokens without an authorization code; intended for JavaScript applications • Resource Owner Password Credentials Grant: Exchanges username and password for tokens; intended for trusted applications • Authorization Code Grant: Exchanges authorization code for tokens; intended for mobile and web applications • Device Flow Grant: Allows devices without keyboard input to get authorization; intended for smart TVs and game consoles • Proof Key Code Exhange Grant: Enhanced authorization code grant; intended for public clients where secrets cannot be stored securely 29 4. O Auth 2.0
30. Implicit Grant 30 4. O Auth 2.0 https://cloudentity.com/developers/b asics/oauth-grant-types/resource-o wner-password-credentials/
31. Implicit Grant • Designed for applications in which the access token is immediately used (Not stored) • Does not support refresh tokens. (When an access token expires, the application must redirect the user to start the entire authorization process from the beginning). 31 4. O Auth 2.0
32. Implicit Grant • authorization-server.com: Authorization server • REQUESTED_SCOPES: Permissions client is requesting • https://internet.xfinity.com/auth_callback: Deep link after successful authorization • CLIENT_ID: The clientID issued to the application by the OAuth server 32 4. O Auth 2.0
33. OAuth 2.0 Grant Types Grant Type: The way an application can get an access token • Implicit Grant: Obtains tokens without an authorization code; intended for JavaScript applications • Resource Owner Password Credentials Grant: Exchanges username and password for tokens; intended for trusted applications • Authorization Code Grant: Exchanges authorization code for tokens; intended for mobile and web applications • Device Flow Grant: Allows devices without keyboard input to get authorization; intended for smart TVs and game consoles • Proof Key Code Exhange Grant: Enhanced authorization code grant; intended for public clients where secrets cannot be stored securely 33 4. O Auth 2.0
34. Resource Owner Password Grant • Client application collects the username and password, which are then sent to the authorization server, skipping the authorization step • Once the authorization server validates the credentials, it returns an access token (and optionally a refresh token) back to the client. • This flow requires a high level of trust in the client application, as it involves sharing sensitive user credentials (username and password). 34 4. O Auth 2.0
35. 35 4. O Auth 2.0 https://cloudentity.com/developers/b asics/oauth-grant-types/resource-o wner-password-credentials/
36. OAuth 2.0 Grant Types Grant Type: The way an application can get an access token • Implicit Grant: Obtains tokens without an authorization code; intended for JavaScript applications • Resource Owner Password Credentials Grant: Exchanges username and password for tokens; intended for trusted applications • Authorization Code Grant: Exchanges authorization code for tokens; intended for mobile and web applications • Device Flow Grant: Allows devices without keyboard input to get authorization; intended for smart TVs and game consoles • Proof Key Code Exhange Grant: Enhanced authorization code grant; intended for public clients where secrets cannot be stored securely 36 4. O Auth 2.0
37. Authorization Code Grant • Application sends user to OAuth server via browser • User approves app’s request on server • Server redirects user to app with authorization code in URL • Application exchanges authorization code for an access token 37 4. O Auth 2.0
38. 38 https://cloudentity.com/developers/b asics/oauth-grant-types/authorizatio n-code-flow/ 4. O Auth 2.0
39. Authorization code • Temporary code that the client will exchange for an access token • Authorization server sends the code in the URL • Client extracts the authorization code from the URL and sends it to the authorization server • Code is short lived and can only be used once 39 4. O Auth 2.0
40. Authorization Code Grant 40 4. O Auth 2.0
41. Authorization Code Grant • Authorization server endpoint: https://id.oauth-example.com/oauth2/authorize • ClientID issued to the application by the OAuth server: client_id=32jk • It indicates that we expect to receive an authorization code: response_type=code • URI to direct the user’s agent to upon completion of the authorization request: redirect_uri=com.oauth-example/kjbhv89%k 41 4. O Auth 2.0
42. 42 4. O Auth 2.0 https://cloudentity.com/developers/b asics/oauth-grant-types/authorizatio n-code-flow/
43. OAuth 2.0 Grant Types Grant Type: The way an application can get an access token • Implicit Grant: Obtains tokens without an authorization code; intended for JavaScript applications • Resource Owner Password Credentials Grant: Exchanges username and password for tokens; intended for trusted applications • Authorization Code Grant: Exchanges authorization code for tokens; intended for mobile and web applications • Device Flow Grant: Allows devices without keyboard input to get authorization; intended for smart TVs and game consoles • Proof Key Code Exhange Grant: Enhanced authorization code grant; intended for public clients where secrets cannot be stored securely 43 4. O Auth 2.0
44. Device Flow • OAuth 2.0 Extension for browserless or limited-input devices • For smart TVs, gaming consoles, printers, and more • Secondary device required 44 4. O Auth 2.0
45. Device Flow 45 4. O Auth 2.0
46. 46 4. O Auth 2.0 https://cloudentity.com/developers/b asics/oauth-grant-types/device/
47. OAuth 2.0 Security • Upon registration, application is issued a client_id and client_secret • These credentials are used to authenticate the client app to the server • If the credentials are hardcoded in a mobile app they can be extracted • An attacker could impersonate the client application to fraudulently request authorization • A secure alternative is using PKCE 47 4. O Auth 2.0
48. OAuth 2.0 Grant Types Grant Type: The way an application can get an access token • Implicit Grant: Obtains tokens without an authorization code; intended for JavaScript applications • Resource Owner Password Credentials Grant: Exchanges username and password for tokens; intended for trusted applications • Authorization Code Grant: Exchanges authorization code for tokens; intended for mobile and web applications • Device Flow Grant: Allows devices without keyboard input to get authorization; intended for smart TVs and game consoles • Proof Key Code Exchange Grant: Enhanced authorization code grant; intended for public clients where secrets cannot be stored securely 48 4. O Auth 2.0
49. PKCE • Proof Key for Code Exchange • Replaces client secret with a dynamically generated secret created by the client • Ideal for mobile apps where client secrets cannot be securely stored • The client generates a secret and sends its hash to the authorization server • During the token exchange, the client sends the original secret to the authorization server, which compares it with the previously received code challenge 49 4. O Auth 2.0
50. PKCE 50 4. O Auth 2.0
51. 51 4. O Auth 2.0 https://cloudentity.com/developers/b asics/oauth-grant-types/authorizatio n-code-flow/
52. RFC 8252 OAuth 2.0 for Native Apps 52 4. O Auth 2.0 • Focused on security • Addresses security concerns by recommending external user agents • Recommends use of private-use URI schemes or app claimed https scheme URIs https://datatracker.ietf.org/doc/html/rfc8252
53. Authenticating via External Browser • Security: The mobile app can’t see your password • Single Sign On (SSO): External browser can maintain login states • Recommended by OIDC • ASWebAuthenticationSession • AndroidCustomTabs 53 4. O Auth 2.0 Slack iOS app
54. Authenticating via External Browser 54 4. O Auth 2.0
55. Android Trusted Web Activities (TWAs) • TWAs enable full-screen web content display within an Android app • Use Chrome Custom Tabs • Cookies or sessions in the Chrome browser available in the TWA • Follow RFC 8252 recommendations to ensure that the user is aware that this process is being performed on a web browser. 55 4. O Auth 2.0
56. Benefits SSO SSO across Xfinity, Xfinity Stream, and Xfinity.com 1. User signs into Xfinity app 2. When switching to Xfinity Stream, the session is shared, and the user's identity is recognized due to the prior sign-in 3. Upon launching the Xfinity.com website, the user is automatically logged in 56 4. O Auth 2.0
57. Native and Webview 57 4. O Auth 2.0
58. 5. Resources 58
59. AppAuth • Maintained by The OpenID Foundation • Open source • Follows best practices RFC 8252 • Orchestrates authentication, authorization code grant, token exchange, token management 59 5. Resources
60. AppAuth Inconsistencies • Android: • iOS: 60 5. Resources
61. AppAuth Inconsistencies • Android: • iOS: 61 5. Resources
62. Alternative Libraries iOS • OAuthSwift 62 5. Resources Android • ScribeJava • Heimdall
63. OAuth 2.1 • OAuth 2.1 simplifies OAuth 2.0 specifications • Mandates the use of PKCE for all clients using Authorization Code flow • Discontinues Implicit Grant Flow and Password Grant • Redirect URIs must match exactly, without wildcard domains • https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-10 63 5. Resources
64. Additional resources • https://www.ietf.org/mailman/listinfo/oauth • OAuth 2.0 simplified: https://www.oauth.com/ 64 5. Resources
65. Thank you! Questions? Chrystian Vieyra Cortés @ChrystianV1 65