OpenID Connect (OIDC) est une couche d'identité bâtie sur le protocole OAuth 2.0 qui permet aux applications d'authentifier les utilisateurs sans avoir à gérer ni stocker leurs identifiants. AWS Application Load Balancer (ALB) s'intègre aux principaux fournisseurs d'identité sociaux (IdP), aux annuaires d'entreprise et à tout IdP conforme à OIDC. Cette intégration simplifie le processus d'authentification et renforce la sécurité en déléguant la gestion des sessions utilisateurs et des jetons d'authentification à un fournisseur tiers de confiance.
Si la connexion est fluide pour l'utilisateur final, identifier l'origine d'un dysfonctionnement peut s'avérer délicat lorsque l'authentification échoue, en raison des sauts supplémentaires entre l'utilisateur et l'application qu'il cherche à atteindre.
Cet article vise à donner de la visibilité sur le déroulement des transactions HTTP, vues sous différents angles, durant le flux d'autorisation par code (authorization code flow).
Si vous souhaitez configurer l'authentification utilisateur sur votre ALB, je vous recommande la documentation officielle d'AWS. AWS propose également un site de démonstration sur lequel vous pouvez tester la fonctionnalité d'authentification.
**Décomposons le flux d'authentification étape par étape —**
La journalisation est essentielle pour préserver la santé, la sécurité et l'efficacité des applications cloud. Elle apporte les informations indispensables au monitoring et au dépannage des applications, et garantit un fonctionnement fluide et sécurisé.
Pour explorer le flux d'authentification en profondeur, j'ai collecté les logs suivants :
- Un fichier HAR depuis le navigateur web de l'utilisateur.
- Les logs d'accès des endpoints de l'IdP (Auth, Token, User-Info), de l'ALB et de l'application cible.
Avant d'examiner les transactions HTTP, je vous recommande de vous familiariser avec les différents composants OIDC et leurs rôles respectifs.
Prérequis —
- L'IdP est configuré pour exécuter le flux d'autorisation par code avec les scopes voulus. Un Client ID et un client secret ont également été générés.
- L'ALB est configuré avec une règle de listener qui déclenche l'action authenticate lorsque le chemin HTTP correspond à
/auth*. Définissez les paramètres de la requête d'authentification, notamment le client ID, le client secret, l'endpoint d'autorisation, l'endpoint de token et l'endpoint user info. Ces paramètres permettent à l'ALB de communiquer avec l'IdP.
Étape 1 — L'utilisateur envoie une requête HTTP à votre application située derrière un ALB avec authentification activée.
Navigateur redirigé vers l'endpoint Auth de l'IdP.
Logs d'accès de l'ALB pour la même transaction —
h2 2024–07–11T18:47:52.382721Z app/demo/25be909a3f190764 109.78.96.82:54871 - -1 -1 -1 302–359 657 "GET https://demo.aws.doit.com:443/auth.html HTTP/2.0" arn:aws:elasticloadbalancing:eu-west-1:21112316:targetgroup/TG/1a24c5faad770fb2 "Root=1–669028d8–653487fd74af592f498329f8" "authenticate"
- L'action d'authentification se déclenche lorsque l'utilisateur envoie une requête HTTP GET à l'ALB.
- Si aucun cookie de session d'authentification n'est présent dans les en-têtes de la requête HTTP, l'ALB génère une réponse HTTP 302 et redirige l'utilisateur vers l'URL spécifiée dans l'en-tête location (l'endpoint d'autorisation de l'IdP).
- Le
redirect_uricorrespond à l'emplacement vers lequel le navigateur est redirigé une fois le code d'autorisation délivré par l'IdP.
Étape 2 — L'utilisateur est redirigé vers l'endpoint d'autorisation de l'IdP.
Requête HTTP vers l'endpoint auth.
- L'utilisateur envoie une requête HTTP à l'endpoint d'autorisation de l'IdP.
- L'endpoint d'autorisation de l'IdP redirige ensuite l'utilisateur vers l'endpoint de connexion de l'IdP (
/login). - L'endpoint de connexion prend en charge l'authentification de l'utilisateur.
Étape 3 — L'utilisateur accède à l'endpoint de connexion.
Requête HTTP vers l'endpoint de connexion.
- L'utilisateur envoie une requête HTTP à l'endpoint de connexion.
- La page de connexion s'affiche avec les champs nom d'utilisateur et mot de passe.
Étape 4 — L'utilisateur s'authentifie.
L'utilisateur saisit son nom d'utilisateur et son mot de passe.
- L'utilisateur saisit ses identifiants sur la page de connexion de l'IdP.
- Une fois l'authentification réussie, l'utilisateur est redirigé vers l'endpoint d'autorisation de l'IdP.
Exemple de payload d'une requête POST —
csrf=izvsVKMB-GxnSvAK6McnPw6uNcZVCqqWxjeU&challenge=cbcab3062ca041399178171a4078d30b&email=user%40name.com&password=complex&submit=Log+in
Étape 5 — L'utilisateur reçoit le code d'autorisation de l'IdP.
Code d'autorisation délivré.
- L'endpoint d'autorisation de l'IdP redirige l'utilisateur vers l'application cliente avec un code d'autorisation.
- Les valeurs initiales du paramètre
statesont conservées afin de maintenir une correspondance 1:1 entre la requête et le callback.
Étape 6 — L'utilisateur revient vers l'ALB avec le code d'autorisation.
L'utilisateur est redirigé vers /auth avec le cookie d'authentification.
Logs d'accès de l'ALB pour la même transaction —
h2 2024-07-11T18:48:27.805659Z app/demo/25be909a3f190764 109.78.96.82:54871 - -1 -1 -1 302 - 423 847 "GET https://demo.aws.doit.com:443/oauth2/idpresponse?code=ory_ac_9j6SCghDyFOexN03pTRP_GSJ5RHduhCLE-L74D2IlSs.zMsOhvXLbIrs0WQLtb43tkUnRZm0lWoI5T0IlNjnoO0&scope=openid&state=Y06EN0RLaODTpBbHGEpfK29AZJcLIpftyWwbyQN8EeiFyOtbN07H2nTXTGUa3DDYX5UgeMDsqP9psViZhPy41Y%2FVkNoJc5%2B6jb8po%2BLXQtcgxRgk9s5T0LgWt53mOEOjxL4nBVQ9Z9X1Sm%2BcZNO%2BFAIlh%2B6t99WKKj3vz1bekHiwdLWp18GUo9cp3eUkPWXbSBXprXOUHk2QlPK9xd7sG3AHyj4urRv3lc97AR4DRrVIECUMOsNP5BlYW6%2FGAg%3D%3D HTTP/2.0" "Root=1-669028fb-6e750f6c5c7fdde45853b7f6" "authenticate"
- L'utilisateur présente le code d'autorisation à l'ALB.
- L'ALB répond avec un code HTTP 302 et redirige l'utilisateur vers l'URI initiale :
https://demo.aws.doit.com/auth.html. - Avant de générer la réponse, l'ALB effectue des requêtes en backchannel vers les endpoints suivants :
L'endpoint Token de l'IdP, pour échanger le code contre un IdToken.
Requête POST vers l'endpoint Token.
L'endpoint UserInfo, pour échanger l'access token contre les claims de l'utilisateur.
Requête vers l'endpoint UserInfo.
Les claims utilisateur, l'access token et le refresh token sont encodés en base64 et chiffrés dans le cookie AWSELBAuthSessionCookie.
Étape 7 — L'utilisateur demande l'URI initiale avec AWSELBAuthSessionCookie défini.
L'utilisateur est authentifié par l'ALB et la requête atteint le backend.
Logs d'accès de l'ALB pour la même transaction —
h2 2024-07-11T18:48:27.824183Z app/demo/25be909a3f190764 109.78.96.82:54871 172.31.11.119:80 0.007 0.001 0.000 200 200 596 3307 "GET https://demo.aws.doit.com:443/auth.html HTTP/2.0" "arn:aws:elasticloadbalancing:eu-west-1:211125377316:targetgroup/healthyTG/1a24c5faad770fb2 "Root=1-669028fb-156c503c2fe1fcdb60e4a5ad" 2024-07-11T18:48:27.815000Z "authenticate,forward" "172.31.11.119:80" "200"
- Les conditions de la règle ALB pour l'action authenticate sont remplies, et le cookie d'authentification est bien présent.
- L'ALB valide le cookie et transmet les informations utilisateur aux cibles via les en-têtes HTTP
X-AMZN-OIDC-*.
En-têtes X-AMZN_OIDC* observés sur la cible —
En-têtes X-AMZN_OIDC*.
x-amzn-oidc-accesstoken— l'access token issu de l'endpoint Token.
x-amzn-oidc-identity— le champ subject (sub) issu de l'endpoint user info.
x-amzn-oidc-data— les claims utilisateur, au format JSON Web Token (JWT).
Les claims utilisateur au format JWT comprennent un en-tête, un payload et une signature, tous encodés en base64 URL. L'ALB utilise ES256 (ECDSA avec P-256 et SHA256) pour générer la signature du JWT.
JWT décodé —
L'en-tête JWT est un objet JSON qui contient l'émetteur, les détails du signataire et l'identifiant de clé. Le payload JWT est un objet JSON qui regroupe les claims utilisateur reçus depuis l'endpoint UserInfo de l'IdP.
La cible (Apache) autorise alors l'utilisateur sur la base de ces claims et lui renvoie une réponse HTTP 200 OK via l'ALB.
Conclusion —
Cet article propose un examen approfondi du déroulement des transactions HTTP durant le flux d'autorisation par code OIDC avec AWS Application Load Balancer (ALB). Il décortique chaque étape, depuis la requête HTTP initiale de l'utilisateur jusqu'à l'authentification et l'autorisation finales, en mettant en lumière les interactions HTTP clés et les éléments de journalisation indispensables au dépannage et à la compréhension du processus.
Pour en savoir plus ou découvrir nos services, n'hésitez pas à nous contacter. Vous pouvez nous joindre ici.