Code d'autorisation

Code d'autorisation type de subvention

Le type de subvention Code d' autorisation est le plus couramment utilisé et le plus largement supporté. C'est un choix populaire pour les services qui offrent des API à consommer par des applications web 3rd. Le flux de type code d'autorisation nécessite l'utilisation d'un navigateur. Pour les applications mobiles, il peut s'agir d'un navigateur intégré.

Dans ce flux, l'utilisateur final s'authentifie et donne son consentement directement au point de terminaison d'autorisation du service d'autorisation OAuth. Il s'agit d'un point de terminaison du navigateur et la méthode d'authentification de l'utilisateur final, ainsi que l'expérience de l'utilisateur en matière de consentement, sont entièrement sous le contrôle du serveur d'autorisation.

Une fois l'authentification et le consentement obtenus, le service d'autorisation génère un code d'autorisation à usage unique et de courte durée, qui est renvoyé à l'application. C'est ce code d'autorisation qui donne son nom à ce type de subvention.

Lorsque l'application reçoit le code d'autorisation, elle établit une connexion directe avec le point de terminaison du service d'autorisation et échange le code d'autorisation contre un jeton d'accès.

PKCE (Proof Key for Code Exchange)

PKCE (prononcé "pixie") est une extension du flux de type d'octroi du code d'autorisation qui permet d'éviter que le code d'autorisation soit intercepté lorsque l'on travaille avec des clients OAuth publics. La spécification PKCE est RFC7636.

Lors de l'utilisation de PKCE, l'application (client OAuth) génère une longue chaîne aléatoire (entre 43 et 128 caractères) au début de chaque flux. La chaîne peut contenir A-Z, a-z, 0-9, un point (.), un tiret (-), un trait de soulignement (_) et un tilde (~). Il s'agit du code_verifier.

L'application effectue une opération SHA256 sur la chaîne code_verifier et encode le résultat en base-64-url. Il s'agit du code_challenge.

Le code_challenge est envoyé au point final d'autorisation du serveur d'autorisation dans le cadre de la demande qui lance le flux du code d'autorisation. Le serveur d'autorisation stocke le code_challenge (indexé par le code d'autorisation).

Lorsque l'application appelle le point de terminaison du jeton du serveur d'autorisation (pour demander un jeton), elle envoie le code_verifier en même temps que le code d'autorisation. Dans le cadre de la validation de la demande, le serveur d'autorisation effectue sa propre opération SHA256 sur le code_verifier et vérifie qu'il correspond au code_challenge associé au code.

📘

What if my application can't implement SHA256?

La spécification PKCE prévoit une option pour les clients qui ne peuvent pas mettre en œuvre une opération de hachage SHA256. Dans ce cas, le code_challenge est le même que le code_verifier. Cela permet d'éviter que le code d'autorisation soit intercepté, mais ne fonctionne pas si un attaquant peut également intercepter la demande d'autorisation.

💎

Jon Harry, IBM Security