Architectures de connexion et de session pour applications mobiles natives avec IdP

Objectif et contexte

Cet article décrit des variantes d’architecture propres pour l’authentification et la gestion de session dans des applications mobiles natives utilisant un fournisseur d’identité externe (IdP) via OAuth 2.0 / OpenID Connect (OIDC).
Objectif :

• séparation claire des mécanismes
  
• variantes comparables
  
• base de décision robuste
  

Fondements de l’architecture (termes précis)

2.1 Composants impliqués

• Application mobile (client public)
  
• Serveur d’autorisation / IdP
  
• Serveur de ressources (API)
  

2.2 Artefacts de jetons

• Jeton d’accès
  • de courte durée (typique : minutes)
    
  • accès aux API
• Jeton de rafraîchissement
  • durée de vie plus longue
    
  • sert à renouveler les jetons d’accès
    
  • hautement sensible

2.3 Deux niveaux de session strictement séparés
(A) Session IdP

• existe dans le navigateur système / ASWebAuthenticationSession / Custom Tabs
  
• permet le SSO
  
• non contrôlée directement par l’application
  
(B) Session applicative

• basée sur des jetons stockés localement
  
• entièrement sous le contrôle de l’application
  
👉 Cette séparation est centrale pour toutes les variantes suivantes.

Dimensions du design (orthogonales !)

Toutes les architectures pertinentes résultent de la combinaison de ces dimensions :

3.1 Dimension 1 : persistance de session (côté application)
Variante 1 : aucune persistance

• jetons uniquement en mémoire (RAM)
  
• perdus après redémarrage de l’application
Variante 2 : session persistante
• jeton de rafraîchissement dans un stockage sécurisé :
  
  • iOS : Keychain
    
  • Android : Keystore
    
• renouvellement automatique des jetons
  

3.2 Dimension 2 : modèle de durée de session
S’applique au jeton de rafraîchissement / session :
Durée de vie absolue
• limite maximale stricte (p. ex. 30 jours)
Timeout d’inactivité
• expiration après inactivité (p. ex. 15 min)
Session glissante
• prolongation lors de l’utilisation
  
• généralement combinée avec :
  
  • rotation
    
  • durée de vie maximale
    
👉 La session glissante n’est pas un pattern à part entière, mais un modèle de durée de vie.

3.3 Dimension 3 : renouvellement des jetons
Sans jeton de rafraîchissement


• le jeton d’accès expire → nouvelle authentification requise
Avec jeton de rafraîchissement
• renouvellement silencieux possible
Avec rotation
• chaque renouvellement → nouveau jeton de rafraîchissement
  
• ancien jeton invalidé

3.4 Dimension 4 : protection d’accès côté application
Indépendamment de l’IdP :

Aucune protection supplémentaire

Ré-authentification locale

• biométrie (Face ID / empreinte digitale)
  
• code PIN de l’appareil
Options :

• au démarrage de l’application
  
• au retour en premier plan
  
• lors d’actions sensibles (step-up)
  

3.5 Dimension 5 : niveau de sécurité des jetons
Jetons « bearer »
• la possession suffit
Jetons liés à l’émetteur
(p. ex. DPoP)
• jeton lié à une clé cryptographique
  
• protection contre le vol de jeton
Liés au matériel
• clé dans Secure Enclave / TEE
  
• liaison forte à l’appareil
  

3.6 Dimension 6 : utilisation de la session IdP (comportement SSO)
SSO actif
• nouvelle connexion possible sans interaction utilisateur
SSO désactivé / forcé
• p. ex. prompt=login
  



Variantes d’architecture de référence

Combinaisons réalistes et pertinentes :
Variante A : session éphémère (haute sécurité)
×

Configuration
• aucune persistance
  
• pas de jeton de rafraîchissement
  
• jeton d’accès court
Propriétés
• la session se termine à la fermeture de l’application
  
• la session IdP peut accélérer la connexion
Avantages
• risque minimal en cas de perte de l’appareil
  
• aucun stockage de jeton
Inconvénients
• très mauvaise UX
  
• redirections fréquentes
Typique pour
• applications hautement sensibles spécialisées
  


Variante B : session persistante (standard)
×

Configuration
• jeton de rafraîchissement en stockage sécurisé
  
• jetons « bearer »
  
• durée de vie absolue
Propriétés
• « rester connecté »
  
• renouvellement silencieux
Avantages
• très bonne UX
  
• implémentation standard
Inconvénients
• risque en cas d’exfiltration de jetons
  
• révocation critique


Variante C : session persistante avec sliding + rotation (best practice)
×

Configuration
• jeton de rafraîchissement + rotation
  
• session glissante + limite absolue
  
• stockage sécurisé
Propriétés
• l’utilisation prolonge la session
  
• les jetons compromis sont rapidement invalidés
Avantages
• excellent équilibre UX / sécurité
  
• largement utilisé aujourd’hui
Inconvénients
• complexité accrue
  
• gestion d’état côté serveur nécessaire


Variante D : persistance + ré-authentification locale
×

Configuration
• comme variante B ou C
  
• en plus
  • biométrie / PIN avant accès
Propriétés
• deux niveaux de protection :
  
• possession (jeton)
  
• présence utilisateur
Avantages
• sécurité fortement améliorée avec bonne UX
  
• protège contre le « shoulder surfing » / appareil déverrouillé
Inconvénients
• friction UX
  
• logique de fallback nécessaire
Typique pour
• banque
  
• cyberadministration


Variante E : session avec jetons liés (haute sécurité moderne)
×

Configuration
• DPoP ou mécanismes similaires
  
• clé dans Secure Enclave / Keystore
  
• souvent combiné avec C ou D
Propriétés
• le jeton seul ne suffit pas
  
• liaison à l’appareil
Avantages
• très haute protection contre le vol de jeton
  
• état de l’art
Inconvénients
• complexe
  
• interopérabilité / débogage exigeants

Comparaison des variantes




Variante	UX	Sécurité	Complexité	Remarque
A Éphémère	❌	✅✅	✅	rarement pertinent
B Persistante	✅	⚠️	⚠️	base
C Sliding + Rotation	✅	✅	⚠️⚠️	best practice
D + Ré-auth	⚠️/✅	✅✅	⚠️⚠️	pour données sensibles
E Sender-Constrained	✅	🚀	❌	haut de gamme

Thèmes critiques (souvent sous-estimés)

6.1 Sémantique de déconnexion

• déconnexion locale → suppression des jetons
  
• déconnexion globale → fin de la session IdP (navigateur)
  
• révocation → invalidation serveur des jetons de rafraîchissement
  

6.2 Perte d’appareil
Questions :

• les jetons sont-ils protégés ?
  
• la biométrie est-elle active ?
  
• existe-t-il une révocation à distance ?
  

6.3 Comportement hors ligne

• jeton d’accès valide → usage hors ligne possible ?
  
• rafraîchissement → nécessite le réseau
  

6.4 Multi-appareils

• un jeton de rafraîchissement par appareil ?
  
• invalidation centralisée ?
  

6.5 Authentification step-up

• ré-authentification pour actions critiques
  
• indépendante de la session
  



Recommandations

• applications standard → variante C
  
• applications sensibles (p. ex. eIAM / autorités) → variante D + option E
  
• sécurité maximale → combinaison C + D + E
  



Conclusion

L’idée clé est :

Il n’existe pas « un seul pattern de connexion », mais un système modulaire de décisions orthogonales.

Une architecture propre signifie :

• ne pas mélanger les dimensions
  
• choisir consciemment la combinaison
  
• adresser explicitement les risques
  

Recommandation : architecture d’authentification et de session pour une application mobile hautement sensible

Objectif

L’application doit :

• répondre à des exigences de sécurité élevées (prévenir les abus en cas de perte de l’appareil)
  
• rester efficace au quotidien
  
• fonctionner dans des conditions variables (utilisation irrégulière, connectivité limitée)
  



Architecture recommandée (combinaison)

2.1 Stratégie de session
→ session persistante avec durée glissante et rotation
Implémentation
• utilisation de jetons de rafraîchissement
  
• stockage dans un secure storage natif
  
• rotation du jeton de rafraîchissement à chaque renouvellement
  
• combinaison de :
  
  • timeout d’inactivité (p. ex. heures)
    
  • durée de vie absolue (p. ex. jours)
    
Justification
• réduit les connexions fréquentes
  
• limite l’impact d’un jeton compromis
  
• standard des systèmes modernes sécurisés
  

2.2 Protection d’accès côté application
→ ré-authentification locale obligatoire
Implémentation
• accès à la session uniquement après :
  
  • biométrie (principal)
    
  • PIN de l’appareil (fallback)
    
• application :
  
  • au démarrage
    
  • après inactivité définie
    
  • lors d’actions sensibles
    
Justification
• protection contre :
  
  • appareils déverrouillés non surveillés
    
  • appareils partagés
    
• augmentation significative de la sécurité sans re-login complet
  

2.3 Niveau de sécurité des jetons
→ jetons liés à l’émetteur (recommandé)
Implémentation
• liaison à une clé spécifique à l’appareil
  
• stockage :
  
  • Secure Enclave (iOS)
    
  • TEE (Android)
    
Justification
• empêche l’utilisation sur un autre appareil
  
• réduit le risque en cas de malware
  

2.4 Intégration IdP
→ login via navigateur système (best practice OIDC)
Implémentation
• ASWebAuthenticationSession (iOS)
  
• Custom Tabs (Android)
  
• réutilisation de la session IdP (SSO)
  
Justification
• pas de gestion de credentials dans l’app
  
• utilisation du MFA existant
  

2.5 Stratégie de logout et révocation
Implémentation
• logout local → suppression des jetons
  
• révocation serveur → invalidation des refresh tokens
  
• optionnel : logout global via IdP
  
Justification
• arrêt contrôlé de session en cas de :
  
  • perte d’appareil
    
  • changement de rôle
    
  • incident de sécurité
    

2.6 Comportement hors ligne
Recommandation
• accès hors ligne aux données non sensibles déjà chargées
  
• pas de refresh sans réseau
  
• actions sensibles uniquement en ligne
  



Niveau de sécurité (évaluation)

Cette combinaison offre :

• haute protection contre la perte d’appareil
  
• haute protection contre le vol de jetons
  
• durée de session maîtrisée
  
• bonne utilisabilité opérationnelle
  



Alternatives écartées

Pas de re-login complet à chaque usage
• friction trop élevée
  
• non viable opérationnellement
Pas de session persistante sans ré-auth
• protection insuffisante en cas d’accès physique
Pas de jetons « bearer » seuls
• risque accru d’exfiltration
  



Mesures complémentaires (optionnelles)

• step-up authentication
  
• attestation de l’appareil
  
• kill de session à distance
  
• détection root/jailbreak (avec prudence)
  



Conclusion

Architecture recommandée :

Session persistante avec rotation
• ré-authentification locale
  
• jetons liés à l’appareil
  

Cette combinaison offre un équilibre robuste entre sécurité et utilisabilité pour des applications à exigences élevées.