Login and Session Architectures for Native Mobile Apps with IdP

Objective and context

This article describes clean architecture variants for authentication and session handling in native mobile apps that use an external identity provider (IdP) via OAuth 2.0 / OpenID Connect (OIDC).
The objective is:
• clear separation of mechanisms
  
• comparable variants
  
• a robust basis for decision-making
  

Architecture foundations (precise terminology)

2.1 Components involved

• Mobile app (public client)
  
• Authorization server / IdP
  
• Resource server (API)
  

2.2 Token artefacts

• Access token
  • short-lived (typically: minutes)
    
  • access to APIs
• Refresh token
  • longer-lived
    
  • used to renew access tokens
    
  • highly sensitive

2.3 Two strictly separated session layers
(A) IdP session

• exists in the system browser / ASWebAuthenticationSession / Custom Tabs
  
• enables SSO
  
• not directly controlled by the app
  
(B) App session

• based on locally stored tokens
  
• fully under the control of the app
  
👉 This separation is central to all following variants.

Design dimensions (orthogonal!)

All meaningful architectures result from combining these dimensions:

3.1 Dimension 1: Session persistence (app side)
Variant 1: No persistence

• tokens only in RAM
  
• lost after app restart
Variant 2: Persistent session
• refresh token in secure storage:
  
  • iOS: Keychain
    
  • Android: Keystore
    
• automatic token renewal
  

3.2 Dimension 2: Session lifetime model
Applies to refresh token / session:
Absolute lifetime
• hard upper limit (e.g. 30 days)
Idle timeout
• expiry after inactivity (e.g. 15 min)
Sliding session
• extended through usage
  
• typically combined with:
  
  • rotation
    
  • max lifetime
    
👉 Sliding is not a separate pattern, but a lifetime model.

3.3 Dimension 3: Token renewal
Without refresh token


• access token expires → new login required
With refresh token
• silent refresh possible
With rotation
• each refresh → new refresh token
  
• old token becomes invalid

3.4 Dimension 4: Access protection at app level
Independent of the IdP:

No additional lock

Local re-authentication

• biometrics (Face ID / fingerprint)
  
• device PIN
Options:

• on app start
  
• on resume
  
• for sensitive actions (step-up)
  

3.5 Dimension 5: Token security level
Bearer tokens
• possession is sufficient
Sender-constrained tokens
(e.g. DPoP)
• token bound to a cryptographic key
  
• protection against token theft
Hardware-bound
• key stored in Secure Enclave / TEE
  
• strongest device binding
  

3.6 Dimension 6: IdP session usage (SSO behaviour)
SSO active
• renewed login possible without user interaction
SSO disabled / enforced
• e.g. prompt=login
  



Reference architecture variants

Now meaningfully cut, realistic combinations:
Variant A: Ephemeral session (high security)
×

Configuration
• no persistence
  
• no refresh token
  
• short access token
Properties
• app session ends when the app is closed
  
• IdP session can speed up login
Advantages
• minimal risk in case of device loss
  
• no token storage
Disadvantages
• very poor UX
  
• frequent redirects
Typical for
• highly sensitive specialist applications
  


Variant B: Persistent session (standard)
×

Configuration
• refresh token in secure storage
  
• bearer tokens
  
• absolute lifetime
Properties
• «Stay logged in»
  
• silent refresh
Advantages
• very good UX
  
• standard implementation
Disadvantages
• risk in case of token exfiltration
  
• revocation is critical


Variant C: Persistent session with sliding + rotation (best practice)
×

Configuration
• refresh token + rotation
  
• sliding session + absolute cap
  
• secure storage
Properties
• active usage extends the session
  
• compromised tokens are invalidated quickly
Advantages
• very good balance of UX / security
  
• widely used today
Disadvantages
• higher complexity
  
• server must manage state


Variant D: Persistence + local re-authentication
×

Configuration
• like variant B or C
  
• in addition
  • biometrics / PIN before access
Properties
• two protection layers:
  
• possession (token)
  
• user presence
Advantages
• significantly increased security with good UX
  
• protects against «shoulder surfing» / unlocked device
Disadvantages
• UX friction
  
• fallback logic required
Typical for
• banking
  
• eGovernment


Variant E: Sender-constrained session (modern high security)
×

Configuration
• DPoP or similar mechanisms
  
• key in Secure Enclave / Keystore
  
• usually combined with C or D
Properties
• token alone is not sufficient
  
• device binding
Advantages
• very high protection against token theft
  
• state of the art
Disadvantages
• complex
  
• interoperability / debugging demanding

Variant comparison




Variant	UX	Security	Complexity	Comment
A Ephemeral	❌	✅✅	✅	rarely appropriate
B Persistence	✅	⚠️	⚠️	baseline
C Sliding + Rotation	✅	✅	⚠️⚠️	best practice
D + Re-Auth	⚠️/✅	✅✅	⚠️⚠️	for sensitive data
E Sender-Constrained	✅	🚀	❌	high-end

Critical detail topics (often underestimated)

6.1 Logout semantics

• local logout → delete tokens
  
• global logout → end IdP session (browser)
  
• revocation → invalidate refresh tokens server-side
  

6.2 Device loss
Questions:

• are tokens protected?
  
• is biometrics enabled?
  
• is there remote revocation?
  

6.3 Offline behaviour

• access token valid → offline possible?
  
• refresh → requires network
  

6.4 Multi-device

• separate refresh tokens per device?
  
• central invalidation?
  

6.5 Step-up authentication

• renewed authentication for critical actions
  
• independent of session
  



-Recommendations

• standard applications → variant C
  
• sensitive applications (e.g. eIAM / public authorities) → variant D + optional E
  
• maximum security → combine C + D + E
  



Conclusion

The key insight is:

There is not «one single login pattern», but rather a modular system of orthogonal decisions.

A clean architecture means:

• do not mix dimensions
  
• choose the combination deliberately
  
• address risks explicitly
  

Recommendation: Authentication and session architecture for a highly sensitive mobile app

Target state

The application should:

• meet high security requirements (prevent misuse in case of device loss)
  
• remain efficient in day-to-day use
  
• function under different operating conditions (varying usage, possibly limited connectivity)
  



Recommended architecture (combination)

2.1 Session strategy
→ Persistent session with sliding lifetime and rotation
Implementation
• use of refresh tokens
  
• storage in platform-protected secure storage
  
• refresh token rotation on every renewal
  
• combination of:
  
  • idle timeout (e.g. hours range)
    
  • absolute lifetime (e.g. days range)
    
Rationale
• avoids frequent logins during operation
  
• limits the impact of token compromise
  
• standard for modern, secure systems
  

2.2 Access protection at app level
→ Mandatory local re-authentication
Implementation
• access to the session only after:
  
  • biometrics (primary)
    
  • device PIN (fallback)
    
• enforced:
  
  • on app start
    
  • after defined inactivity
    
  • for sensitive actions
    
Rationale
• protection for:
  
  • unlocked, unattended devices
    
  • shared devices
    
• significant security increase without a full re-login
  

2.3 Token security level
→ Sender-constrained tokens (recommended)
Implementation
• binding tokens to a device-specific key
  
• key storage in:
  
  • Secure Enclave (iOS)
    
  • Trusted Execution Environment (Android)
    
Rationale
• prevents use of intercepted tokens on other devices
  
• reduces risk in case of malware or memory access
  

2.4 IdP integration
→ System-browser-based login (OIDC best practice)
Implementation
• use of:
  
  • ASWebAuthenticationSession (iOS)
    
  • Custom Tabs (Android)
    
• use of existing IdP session (SSO)
  
Rationale
• avoids credential handling in the app
  
• leverages existing authentication strength (e.g. MFA)
  

2.5 Logout and revocation strategy
Implementation
• local logout
  
  • complete deletion of all tokens
    
• server-side revocation
  
  • invalidation of refresh tokens
    
• optional:
  
  • global logout via IdP
    
Rationale
• controlled session termination in case of:
  
  • device loss
    
  • role change
    
  • security incidents
    

2.6 Offline behaviour
Recommendation
• allow offline access to non-sensitive, already loaded data
  
• no token renewal without network
  
• allow sensitive actions only online
  



Security level (classification)

The recommended combination corresponds to:

• high protection against device loss
  
• high protection against token theft
  
• controlled session lifetime
  
• good operational usability
  



Deliberately rejected alternatives

No full re-login on every use
• too much friction
  
• not operationally practical
No purely persistent session without re-auth
• insufficient protection in case of physical access
No pure bearer tokens without additional protection
• increased risk in case of token exfiltration
  



Additional measures (optional, depending on protection needs)

• step-up authentication for critical actions
  
• device binding with attestation
  
• remote session kill
  
• root/jailbreak detection (use with caution)
  



Conclusion

A multi-layered security architecture is recommended:

Persistent, rotating session
• local re-authentication
  
• device-bound tokens
  

This combination achieves a robust balance between security and usability and is suitable for applications with elevated protection requirements.