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
Establishes and promotes internet standards • Open, international community • Publishes technical documents called Requests for Comments (RFC) • Key standards: TCP/IP, HTTP, OAuth
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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
chrystianv
greggifford
tapps
tmiket
mfonobong
baasie
axbom
uxyall
seathinner
rakko
marketingsoph
skipperchong
malarkey
![Thank you! Questions? Chrystian Vieyra Cortés @ChrystianV1 [email protected] 69](https://files.speakerdeck.com/presentations/810e34b158cd41f59af70c92b79c3370/slide_68.jpg){kind=link}