OAuth 2.0 & OpenID Connect

Comprendre OAuth 2.0 et OpenID Connect est fondamental pour s’intégrer correctement avec Auris. Cette page explique les protocoles, leurs différences, les grant types supportés par Auris et comment Auris les implémente en interne.

Qu’est-ce qu’OAuth 2.0 ?

OAuth 2.0 (RFC 6749) est un framework d’autorisation. Il fournit un moyen standard pour un utilisateur d’accorder à une application tierce un accès limité à ses ressources sur un autre service, sans exposer ses credentials à l’application tierce.

L’intuition clé est qu’OAuth 2.0 concerne la délégation d’accès — pas la vérification d’identité. Quand tu te connectes à une app tierce avec “Se connecter avec Google,” Google utilise OAuth 2.0 pour accorder à l’app l’accès à tes données de profil, pas pour prouver que tu es bien qui tu dis être. C’est une couche séparée.

Rôles Principaux dans OAuth 2.0

Dans Auris, l’Authorization Server et le Resource Server font partie de la même plateforme. Le Client est ton application et le Resource Owner est ton utilisateur.

Ce qu’OAuth 2.0 N’Est Pas

OAuth 2.0 ne :

• Définit pas comment un utilisateur prouve son identité (pas de protocole de login)
• Spécifie pas ce qu’il y a dans un access token
• Définit pas comment les tokens sont validés par les resource servers

Ces lacunes ont conduit à la création d’OpenID Connect.

Qu’est-ce qu’OpenID Connect ?

OpenID Connect (OIDC) est une couche d’authentification construite au-dessus d’OAuth 2.0. Elle répond à la question qu’OAuth 2.0 laisse sans réponse : “Qui est cet utilisateur ?”

OIDC étend le flux Authorization Code d’OAuth 2.0 en introduisant :

1. L’ID Token — un JWT signé contenant l’identité de l’utilisateur (ID utilisateur, email, nom, etc.)
2. L’Endpoint UserInfo — où le client peut récupérer des claims utilisateur supplémentaires
3. Claims Standardisés — un ensemble défini de noms de claims (sub, email, name, picture, etc.)
4. Document Discovery — une URL connue décrivant les endpoints du provider

Quand tu utilises OIDC, tu demandes le scope openid en plus de tout autre scope. La présence de openid dans le scope indique à l’authorization server d’émettre un ID Token en plus de l’access token.

La Différence en Pratique

Dans Auris, chaque flux de login hébergé est OIDC — le scope openid est inclus par défaut et la réponse token contient toujours un ID token en plus des access et refresh tokens.

Grant Types Supportés par Auris

OAuth 2.0 définit plusieurs “grant types” — des flux pour obtenir des tokens selon le type de client et le cas d’usage.

1. Authorization Code + PKCE (Recommandé)

Le flux standard pour les applications user-facing (web apps, apps mobiles, SPA, CLI avec redirect browser). PKCE (Proof Key for Code Exchange, RFC 7636) est ajouté pour protéger contre les attaques d’interception de code.

Quand l’utiliser : Toute application où un utilisateur réel se connecte de manière interactive.

Résumé du flux :

1. L’app génère un code verifier et un code challenge
2. Le browser est redirigé vers la page de login hébergée d’Auris avec le code challenge
3. L’utilisateur s’authentifie
4. Auris redirige vers l’app avec un authorization code
5. L’app échange le code + code verifier contre des tokens

Consulte la page Flux PKCE pour un guide complet étape par étape.

2. Client Credentials (M2M)

Utilisé pour la communication machine-to-machine où aucun utilisateur n’est impliqué. Un service s’authentifie en utilisant son propre client_id et client_secret pour obtenir un access token avec des scopes définis par le serveur.

Quand l’utiliser : Services backend, jobs planifiés, pipelines CI/CD, microservices internes.

curl -X POST https://api.altovar.net/api/auth/token \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "client_credentials",
    "client_id": "m2m-service-id",
    "client_secret": "m2m-service-secret",
    "scope": "read:users manage:roles"
  }'

L’access token résultant a "type": "m2m" dans son payload et ne porte que les scopes déclarés — aucune identité utilisateur.

3. Device Authorization Grant (RFC 8628)

Pour les dispositifs qui ne peuvent pas ouvrir directement un browser : smart TV, outils CLI, dispositifs IoT, consoles de jeu.

Quand l’utiliser : Dispositifs avec entrée limitée ou outils CLI qui ne peuvent pas rediriger le browser de l’utilisateur.

Résumé du flux :

1. Le dispositif demande à Auris un device code et un user code
2. Auris retourne device_code, user_code et verification_url
3. Le dispositif affiche le user_code et demande à l’utilisateur d’aller au verification_url sur un autre dispositif
4. L’utilisateur s’authentifie sur son téléphone ou ordinateur et approuve le dispositif
5. Le dispositif fait du polling sur l’endpoint token jusqu’à ce que l’utilisateur approuve
6. L’endpoint token retourne les tokens une fois approuvé

4. Token Exchange (RFC 8693)

Permet d’échanger un token contre un autre — utilisé pour les scénarios d’impersonification et de délégation dans des architectures multi-services complexes.

Quand l’utiliser : Services backend qui doivent agir au nom d’un utilisateur, ou outils admin qui doivent impersonifier un utilisateur pour le débogage.

5. CIBA (Client-Initiated Backchannel Authentication)

Une extension OpenID Connect qui permet à un client de démarrer l’authentification pour un utilisateur sans redirect browser. À la place, l’utilisateur reçoit une notification push ou un message out-of-band et approuve ou refuse la demande d’authentification.

Quand l’utiliser : Authentification dans les centres d’appels, approbations IoT, flux haute garantie où tu veux authentifier l’utilisateur sur un dispositif de confiance séparé.

Auris supporte CIBA dans les modes poll, ping et push.

Endpoints OAuth 2.0 dans Auris

Scopes dans Auris

Les scopes OAuth 2.0 sont des chaînes séparées par des espaces définissant quel accès un token accorde.

Scopes OIDC Standard

Scopes M2M

Les tokens M2M utilisent des scopes personnalisés définis par application dans la Console. Exemples :

• read:users — accès en lecture seule aux données utilisateur
• manage:roles — CRUD complet sur les rôles
• read:audit-logs — accès à l’API du log d’audit

Comment Auris Implémente OAuth 2.0

Auris est construit sur Keycloak comme engine d’identité sous-jacent, avec Auris qui étend et enveloppe la fonctionnalité de Keycloak.

Keycloak comme Engine de Base

Keycloak gère :

• Stockage et vérification des credentials utilisateur
• Gestion des sessions et émission des tokens
• Fédération SAML et OIDC
• Ponts pour les protocoles de login social

Extensions Auris sur Keycloak

Auris ajoute au-dessus de Keycloak :

• Pages de Login Hébergées : UI de login entièrement branded, domaine personnalisé
• Actions Engine : Hooks de code côté serveur personnalisés qui s’exécutent pendant login, inscription et émission de token
• Custom JWT Claims : Injection de claims configurable par application au moment de l’émission du token
• PKCE Enforcement : Appliqué au layer Auris (pas optionnel)
• MFA Adaptatif : Scoring de risque et authentification step-up basée sur IP, dispositif et comportement
• Intégration FGA : Vérifications d’autorisation fine-grained au niveau ressource

Concepts Associés

• Les Tokens Expliqués — Access tokens, refresh tokens et ID tokens en détail
• Flux PKCE — Flux Authorization Code avec Proof Key for Code Exchange
• Hosted Login (Universal Login) — Comment Auris implémente OAuth2 via des pages hébergées
• Guide Hosted Login — Intégration PKCE étape par étape
• Credentials M2M — Flux OAuth2 serveur-à-serveur