OAuth Done Right: Secure Authentication for Android Apps

Transcript

1. OAuth Done Right: Secure Authentication for Android Apps CHRYSTIAN VIEYRA CORTÉS Director of Engineering Thomson Reuters 1
2. Thomson Reuters 2
3. Overview 1. Background 2. Jargon 3. Tokens 4. OAuth 2.0 5. Handing Tokens on Android 6. Step-Up Authentication 7. Resources 8. 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 • 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 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 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 • Access tokens cannot be revoked 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. 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 32 4. O Auth 2.0
33. Resource Owner Password Grant • Client application collects the username and password, which are then sent to the authorization server • 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). 33 4. O Auth 2.0
34. 34 4. O Auth 2.0 https://cloudentity.com/developers/b asics/oauth-grant-types/resource-o wner-password-credentials/
35. 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 35 4. O Auth 2.0
36. 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 36 4. O Auth 2.0
37. 37 https://cloudentity.com/developers/b asics/oauth-grant-types/authorizatio n-code-flow/ 4. O Auth 2.0
38. 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 38 4. O Auth 2.0
39. 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 39 4. O Auth 2.0
40. Device Flow • OAuth 2.0 Extension for browserless or limited-input devices • For smart TVs, gaming consoles, printers, and more • Secondary device required 40 4. O Auth 2.0
41. Device Flow 41 4. O Auth 2.0
42. 42 4. O Auth 2.0 https://cloudentity.com/developers/b asics/oauth-grant-types/device/
43. 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 43 4. O Auth 2.0
44. 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 44 4. O Auth 2.0
45. 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 45 4. O Auth 2.0
46. PKCE 46 4. O Auth 2.0
47. 47 4. O Auth 2.0 https://cloudentity.com/developers/b asics/oauth-grant-types/authorizatio n-code-flow/
48. RFC 8252 OAuth 2.0 for Native Apps 48 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
49. 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 • AndroidCustomTabs 49 4. O Auth 2.0
50. 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. 50 4. O Auth 2.0
51. 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 51 4. O Auth 2.0
52. 5. Handing Tokens 52
53. The Old Way is Now the Wrong Way For years, EncryptedSharedPreferences from the AndroidX Security library was the standard for securing tokens. This library is now deprecated and should NOT be used. Why the shift? • Platform Security Evolved • It Encouraged Bad Habits • No Longer Maintained 53 5. Handling Tokens
54. The New Best Practice: Trust The Platform With the official library gone, the guidance has simplified: rely on the platform's built-in security. For most applications, the recommended approach is to use standard SharedPreferences 54 5. Handling Tokens
55. The Community Fork For teams that understand the risks but need a drop-in replacement, developer Ed George is kindly maintaining a fork of the original library. Repo: github.com/ed-george/encrypted-shared-preferences 55 5. Handling Tokens
56. 6. Step-Up Authentication 56
57. Core Concept: A security pattern that requires an already logged-in user to re-authenticate before performing a high-risk action. Main Goal: It's not about identifying the user, but verifying their current presence and intent. Common Use Cases: • Financial: Initiating a money transfer or adding a new payment method. • E-commerce: Changing a shipping address during checkout. • Account Security: Changing a password, email, or deleting an account. 57 6.Step-Up What is Step-Up Authentication?
58. Step-Up Auth 58 6.Step-Up
59. Key OAuth/OIDC Parameters: • prompt=login: Forces the user to re-enter their credentials (e.g., password). • acr_values: Requests a specific level of authentication (e.g., requires multi-factor). The Android Implementation: • It's a minor modification to your existing login code. • Add the prompt or acr_values parameter to your AuthorizationRequest. 59 6.Step-Up How to Implement Step-Up
60. 7. Credential Manager 60
61. Android's Credential Manager What it is: A unified Android API for all sign-in methods. What it handles: • Passkeys (passwordless) • Saved Passwords • Federated Sign-In ("Sign in with Google") Why use it: • Provides a standard, trusted native UI. 61 7. Credential M anager https://android-developers.googleblog.com/2023/10/simple-and-secure-sign-in- on-android-with-credential-manager-passkeys.html
62. Connecting Credential Manager to Your OAuth Flow 62 7. Credential M anager
63. 8. Resources 63
64. AppAuth • Maintained by The OpenID Foundation • Open source • Follows best practices RFC 8252 • Orchestrates authentication, authorization code grant, token exchange, token management 64 8. Resources
65. AppAuth Inconsistencies • Android: • iOS: 65 8. Resources
66. AppAuth Inconsistencies • Android: • iOS: 66 8. Resources
67. 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 67 8. Resources
68. Additional resources 68 8. Resources
69. Thank you! Questions? Chrystian Vieyra Cortés @ChrystianV1 chrystian.vieyracortes@thomsonreuters.com 69