Sécurité
Couche d’identité au-dessus d’OAuth 2.0 : prouve qui est l’utilisateur, en plus de donner accès aux ressources.
Sur OAuth 2.0 : Ajoute un ID Token (JWT) prouvant l’identité, en plus de l’access token qui autorise l’accès aux ressources.
Flux : Authorization Code + PKCE pour les apps web et mobiles ; endpoints /authorize, /token, /userinfo.
Ce qui arrive si on s'en passe
Employer OAuth 2.0 seul pour savoir qui est l'utilisateur revient à confondre la clé d'une pièce avec la carte d'identité de celui qui la tient : un jeton d'accès autorise des ressources, il ne prouve pas l'identité, et une application qui s'en contente peut accepter un jeton émis pour une autre application et ouvrir la session du mauvais utilisateur. OpenID Connect fournit pour cela un ID Token signé, qu'il faut encore vérifier. Sans PKCE, un code d'autorisation intercepté, sur mobile notamment, s'échange contre des jetons au profit de qui l'a volé. Les formalités d'identité sont fastidieuses, mais moins que d'expliquer pourquoi un inconnu lit la messagerie du directeur.
Explication de la marmotte
Imagine que tu veux entrer dans une fête. Le système classique te donne juste un ticket qui dit que tu peux entrer, mais il ne dit pas qui tu es vraiment. Ce dont on parle ici, c’est un moyen qui, en plus de te donner ce ticket, montre aussi une carte d’identité pour prouver que c’est bien toi. Comme ça, la personne à l’entrée sait non seulement que tu as le droit d’être là, mais aussi qui tu es exactement. C’est un peu comme un contrôle plus complet pour être sûr de ton identité.
Où ce terme est utilisé
- Pièges OAuth 2.1 : PKCE, redirections et scopes (20 occurrences)
- OIDC, SAML et OAuth 2.1 en fédération (19 occurrences)
- OIDC pour sécuriser les identifiants CI/CD (16 occurrences)
- Configurer GitHub Actions OIDC vers AWS sans clé statique (15 occurrences)
- Le flux OAuth avec PKCE en une page (14 occurrences)
- Configurer OIDC entre Keycloak et application interne (13 occurrences)
- Authentifier une API B2B hors annuaire interne (12 occurrences)
- Gérer les accès externes des prestataires (12 occurrences)
- Sécuriser les identifiants CI/CD avec OIDC (12 occurrences)
- Mettre en place la fédération d’identité de charge (9 occurrences)
