Comprendre OpenID-Connect et l'utiliser dans les applications moblies

1. 1/22
SSO JUSQUE DANS LES APPLICATIONS MOBILES
AVEC OPENID-CONNECT

2. 2/22
SSO, À QUOI ÇA SERT ?
SSO = SINGLE-SIGN-ON
ÇA SERT À PARTAGER L’AUTHENTIFICATION ET L’IDENTITÉ (OU UN AVATAR)
• Mais ça permet de répondre aussi aux besoins AAA
PLUS-VALUE D’UN SSO :
• Une application avec un système d’authentification propre coûte en moyenne 15 à 25 %
plus cher
• Garanties de l’unicité du compte dans l’entreprise, meilleure auditabilité

3. 3/22
LE AAA ?
AAA SIGNIFIE AUTHENTICATION-AUTHORIZATION-ACCOUNTING. UN PROJET DE
SSO DOIT POUVOIR
1) Authentifier de manière centralisée les utilisateurs et partager les données
2) Gérer les droits :
• Soit dans le SSO
• Soit dans l’appli
• [Hybride] soit le SSO fournit à l’appli les données nécessaire au contrôle
3) Tracer les actions utilisateurs. En pratique le SSO fournit un identifiant à insérer dans les
traces

4. 4/22
LA NORMALISATION (2005 - 2015)
CHAQUE SSO :
• avait sa façon de communiquer avec les applications
• était contingenté à son entreprise
IL EST APPARU DANS LES ANNÉES 2000, L’IDÉE DE NORMALISER DES ÉCHANGES :
• entre entreprises (Liberty Alliance puis SAML)
• au sein du monde universitaire (CAS puis Shibolleth)
CES PROTOCOLES SONT DEVENUS ÉGALEMENT DES PROTOCOLES INTERNES

5. 5/22
ET OPENID-CONNECT ?
EN PARALLÈLE, LES « GRANDS » ONT VOULU FAIRE DE LEUR LOGINS DES IDENTITÉS MONDIALES
(« S’AUTHENTIFIER AVEC GOOGLE »,…)
• Mais le seul protocole valable au niveau sécurité (SAML) ne permettait pas d’enrôler facilement les partenaires
• Chacun a donc développé son protocole
LA FONDATION OPENID A CRÉÉ UN PROTOCOLE CAPABLE DE RÉPONDRE À CES BESOINS : OPENID-CONNECT
• Basé sur le meilleur protocole web de partage des fichiers/données (OAuth2)
• Norme modulaire : des extensions sont possibles
• A ne pas confondre avec le protocole OpenID 2.0 qui n’a jamais percé
(TRÈS) PROGRESSIVEMENT, LES « GRANDS » REMPLACENT LEUR PROTOCOLES MAISONS PAR OIDC

6. 6/22
ET LES AUTRES PROTOCOLES ?
CERTAINS CONTINUENT DE BIEN SE PORTER :
• SAML qui reste très utilisé (y compris la version limitée « Shibboleth »)
• CAS qui reste bien présent dans le monde éducatif
MAIS D’AUTRES SONT MORT-NÉS :
• OpenID de la fondation éponyme
• Web-ID de Mozilla
• …

7. 7/22
OIDC
FLUX INITIÉ PAR L’APP
APPLICATION RECONNUE
PAR MOT DE PASSE
DONNÉES DU SERVEUR OPENID-CONNECT
SIGNÉES

8. 8/22
SAML (POST)
FLUX INITIÉ PAR L’APP
OU PAR LE SERVEUR
RECONNAISSANCE MUTUELLE
PAR CLEFS PUBLIQUES
TOUTES LES REQUÊTES SONT SIGNÉES
VOIRE CHIFFRÉES

9. 9/22
2. REQUÊTE OIDC :
• Possibilité de signer et chiffrer la requête
5. RÉCUPÉRATION DU CODE
• Egalement possibilité de signer et chiffrer
les demandes et les réponses
… MAIS TRÈS PEU D’IMPLÉMENTATION OIDC
DISPOSENT DE CES ÉLÉMENTS DE SÉCURISATION
MAIS OIDC PEUT AUSSI ÊTRE TRÈS SÉCURISÉ

10. 10/22
OIDC & SÉCURITÉ EN DÉTAIL (WEB)
2. LA DEMANDE DE CODE
• Le code est un aléa qui permettra d’obtenir
un access_token
• Client public, aucune sécurité
• Client public + PKCE, la requête inclus un
hash(code_challenge), le code_challenge
sera demandé à la requête suivante
• Client secret, pas de secret ici mais la résolution
du code nécessitera une authentification
• Client authentifié : la requête se fait en utilisant
un JWT signé (JWS)

11. 11/22
OIDC & SÉCURITÉ EN DÉTAIL (WEB)
5. LA RÉSOLUTION DU CODE
• En échange du code, le serveur délivre
un access_token et un id_token
• Client public, pas d’autre sécurité que la connaissance
du code
• Client public + PKCE, le code_challenge
est exigé, le serveur vérifie que le hash
• Client secret
● authentification par login + mot de passe de l’application
● Authentification et requête par JWT signé (JWS)
• Réponse :
● JWT signé (JWS)
● JWT signé et chiffré (JWE)

12. 12/22
OIDC & SÉCURITÉ EN DÉTAIL (WEB)
5. L’OBTENTION DES DONNÉES
• Le serveur délivre les données de l’utilisateur
en fonction des scopes demandés
• Authentification :
● access_token dans les données du formulaire
● access_token dans l’en-tête Authorization
• Réponse :
● JWT signé (JWS)
● JWT signé et chiffré (JWE)

13. 13/22
OIDC & MAINTIENT DE LA CONNEXION
OIDC OFFRE UN DISPOSITIF DE PERSISTENCE (OFFLINE_ACCESS)
• Le serveur peut délivrer un refresh_token
● Permet de demander un nouvel access_token
via l’API /token lorsque l’access_token est
expiré
● Peut également délivrer un nouveau refresh_token
POURQUOI MAINTENIR UN LIEN AVEC LE SERVEUR OIDC ?
• Au delà de la première obtention de données, le maintien du lien permet de garder les
données de l’utilisateur à jour

14. 14/22
LE PROBLÈME DU SSO ENTRE APPLICATIONS MOBILES
SSO = SINGLE-SIGN-ON
• Donc après avoir ouvert la première appli, on ne réauthentifie pas pour les suivantes
DANS LE NAVIGATEUR, PAS DE PROBLÈMES
• Le navigateur partage des contextes entre pages, en particulier les cookies
• Le serveur OIDC peut donc maintenir en mémoire la connection
MAIS DANS LE CONTEXTE DES APPLICATIONS MOBILES...
• Les applications mobiles sont des sortes de conteneurs qui ne partagent pas grand chose
• Mais lorsqu’elles sont signées par la même entreprise, il y a une voie

15. 15/22
OPENID-CONNECT NATIVE SSO FOR MOBILE APP
IDÉE :
• Les 2 grandes plateformes de mobile disposent d’un système “keychain”
● Permet de partager des données entre applications signées par la même organisation
• OpenID-Connect est basé sur le protocole Oauth2 qui dispose d’un système d’échange de
tokens
• La fondation OpenID a donc proposé une spécification permettant d’utiliser ces 2 systèmes
pour faire du SSO entre appli mobiles
● La première appli s’authentifie normalement
● Elle stocke ensuite l’id_token et un nouveau token appelé device_secret
● Les applis suivantes utiliseront ces 2 éléments pour obtenir leurs propres access_token

16. 16/22
BONNE PRATIQUES POUR UTILISER OIDC EN APP MOBILE
INTÉGRER OIDC DIRECTEMENT DANS L’APPLICATION MOBILE N’EST GÉNÉRALEMENT PAS
UNE BONNE IDÉE :
• L’intérêt du SSO est d’avoir en un seul point le système d’authentification
Un seul point pour intégrer les changement de politiques
● Changement de politiques de mots de passe
● Adoption d’une authentification multi-facteurs
● Passwordless
● …
• La mise à jour des appli mobiles n’est pas toujours garantie
EN PRATIQUE DONC, ON APPELLE LE NAVIGATEUR POUR LA PHASE D’AUTHENTIFICATION

17. 17/22
BONNE PRATIQUE POUR UTILISER OIDC EN APP MOBILE
APPEL DU NAVIGATEUR POUR LA PHASE D’AUTHENTIFICATION
App 1 Navigateur Serveur OIDC
Lancement
Flux OIDC
Demande de code
Récupération du code
Utilisation du code pour obtenir
Les tokens et les données

18. 18/22
BONNE PRATIQUE POUR UTILISER OIDC EN APP MOBILE
APPEL DU NAVIGATEUR POUR LA PHASE D’AUTHENTIFICATION
App 1 Navigateur Serveur OIDC
Lancement
Flux OIDC
Demande de code
Récupération du code
Utilisation du code pour obtenir
Les tokens et les données
Stockage du device_secret
et de l’id_token

19. 19/22
SSO AVEC UNE DEUXIÈME APPLI
APPEL DU NAVIGATEUR POUR LA PHASE D’AUTHENTIFICATION
App 2 Navigateur Serveur OIDC
Appel OIDC / Oauth2
“Token exchange”
Récupération du
device_secret et de l’id_token
App 1
Récupération de nouveaux
access_token, id_token, refresh_token

20. 20/22
UTILISATION DU KEYCHAIN D’ANDROÏD
• Stockage d’un token dans le keychain :
KeyChainConnection keyChainConnection = new KeyChainConnection(context);
keyChainConnection.saveToken("mon_token");
keyChainConnection.disconnect();
• Accès depuis l’app 2
KeyChainConnection keyChainConnection = new KeyChainConnection(context);
String token = keyChainConnection.getToken();
keyChainConnection.disconnect();

21. 21/22
POUR ALLER PLUS LOIN
SPÉCIFICATIONS OPENID-CONNECT
• https://openid.net/specs
• OpenID-Connect Native SSO for Mobile Apps :
https://openid.net/specs/openid-connect-native-sso-1_0.html
• Implémentation dans Lemonldap::NG : https://lemonldap-ng.org/

22. 22/22
QUESTIONS ?