Identity and sessions
OAuth, passkeys, biometrics, device registration and recovery.
Why mobile OAuth uses PKCE
Mobile applications are distributed public clients; embedded shared secrets cannot remain confidential. PKCE binds authorization-code exchange to the initiating flow.
Read the guideUsing the system browser for mobile sign-in
A system browser or suitable platform authentication session helps keep the user's password out of the application's direct control.
Read the guideRegistering OAuth redirect URIs securely
Redirect URIs determine where authentication results return. Broad matching or uncontrolled destinations weaken the flow.
Read the guideID tokens versus access tokens
ID tokens describe authentication context; access tokens authorize access to resources. Interchanging them without regard to purpose causes validation errors.
Read the guideRotating mobile refresh tokens
A stolen long-lived refresh token can prolong account access. Rotation and reuse detection help manage that risk.
Read the guideRevoking mobile sessions remotely
Remote revocation helps with lost devices and suspicious activity. Its effect extends beyond a logout message.
Read the guideProtecting Android passkey integration
Passkeys can reduce password use, but account binding and server validation still need correct implementation. Credential Manager supports the platform experience.
Read the guideiOS passkeys and application identity
Passkeys form part of the application-service identity flow. Assess registration, sign-in and recovery together.
Read the guideRecovery policies for passkey accounts
A strong sign-in method loses value if a weaker recovery route permits takeover. Recovery deserves equal attention.
Read the guideStep-up verification for sensitive transactions
Different actions need different assurance. Step-up rechecks identity or approval for higher-risk operations.
Read the guideDevice binding and account registration
Device binding links accounts to specific registrations. It is distinct from collecting hardware identifiers; key-based registration may be suitable.
Read the guideWhat DPoP adds to mobile access tokens
DPoP binds OAuth tokens to proof of key possession, adding a constraint against token copying alone.
Read the guideValidating JWT claims in mobile APIs
Reading JWT fields is not validation. Verify signatures together with expected issuer and audience.
Read the guideWhere to store mobile access tokens
Storage depends on lifetime, background needs and device-loss risk. Plain preferences and protected platform storage offer different properties.
Read the guideIs local biometrics proof of identity to a server?
Local biometrics authenticates interaction with the device user. A client-supplied success field is not sufficient account evidence.
Read the guideSMS codes and mobile account security
SMS can add verification, but numbers change ownership and codes can be socially engineered. Account for these limits in sensitive flows.
Read the guideTime and recovery in TOTP flows
TOTP generates time-based codes. Validation needs defined windows, replay handling and recovery.
Read the guideUnintended approval in push authentication
Repeated prompts can encourage thoughtless acceptance. Show clearly which request is being approved.
Read the guideProtecting mobile password reset
Reset restores account control and is therefore a security flow, not a minor auxiliary page.
Read the guideSupport-team authority in account recovery
Support recovery can become a separate route around technical controls. It needs evidence, bounded privileges and records.
Read the guideIdle timeouts in mobile sessions
Idle duration, absolute session lifetime and transaction approval are different time limits. Choose them for the use case.
Read the guideSeparating multiple mobile accounts safely
Multiple accounts require explicit ownership of caches, keys and tasks. Changing the displayed username is insufficient.
Read the guideCombining risk signals with authentication
Device and application risk can inform authentication. A signal does not prove malicious intent.
Read the guideSeparating login from transaction authorization
Signing in does not approve every sensitive action. Bind authorization to specific content and user intent.
Read the guideAccount deletion and security-data lifecycle
Deletion combines identity, retention and session revocation. One user must not be able to delete another's account.
Read the guide