Frise : l’évolution d’OAuth et d’OpenID Connect

Première version : chaque appel est signé. Complexe à implémenter, d’où la suite.

Le protocole devient une RFC.

Le cadre actuel : code, implicit, password, client credentials, plus les jetons Bearer.

Invalider un jeton avant son expiration.

L’identité au-dessus d’OAuth : ID token, userinfo, scopes standard, découverte.

Le format de jeton signé, et l’authentification par assertion (SAML ou JWT) au lieu d’un secret. ID-Kit : JWT et assertion JWT côté fournisseur de test (pas l’assertion SAML).

Un client peut se déclarer par API.

Lie le code à celui qui l’a demandé. Né pour le mobile, aujourd’hui exigé partout.

Demander au fournisseur si un jeton est actif.

Navigateur système plutôt que vue intégrée. Fin du mot de passe saisi dans l’application.

La découverte d’OAuth (équivalent de .well-known/openid-configuration).

Se connecter depuis un appareil sans clavier, via un autre écran.

Échanger un jeton contre un autre (délégation, changement d’audience).

Authentification client par certificat et jetons liés au certificat.

La demande d’autorisation est un JWT signé.

Déposer la demande d’autorisation de serveur à serveur.

Un format standard pour les jetons d’accès JWT (typ at+jwt).

CIBA : authentification sur un autre appareil. JARM : réponse d’autorisation sous forme de JWT signé.

Protège contre l’attaque « mix-up ».

Autorisations détaillées (« payer 50 € à X ») au lieu de simples scopes.

Un jeton lié à une clé du client ; une API peut exiger une authentification plus forte.

Core, Discovery, Dynamic Registration et les spécifications de déconnexion publiées en ISO/IEC 26131 à 26139.

Le « BCP » qui enterre implicit et password et impose PKCE et la comparaison exacte des redirect_uri.

Une API annonce quel serveur d’autorisation elle accepte.

Profil de sécurité financier (PAR, PKCE, jetons liés) et identités vérifiables : émission et présentation de justificatifs dans un portefeuille numérique.

Divulgation sélective dans un JWT ; signaux de sécurité partagés entre fournisseurs (révocation continue).

Chaînes de confiance entre fournisseurs et clients, à l’échelle (éducation, administrations).

Consolide OAuth 2.0 et les bonnes pratiques : implicit et password supprimés, PKCE obligatoire. Pas encore une RFC au 31 octobre 2026.

Identity chaining (propager l’identité entre domaines), rfc7523bis (révision de l’authentification par JWT), Status List, révision des bonnes pratiques JWT.

Des dizaines de brouillons sur l’autorisation d’agents : Transaction Tokens, délégation, Identity Assertion Authorization Grant. Rien de stabilisé : à suivre, pas à implémenter.