Autorisation Code d'autorisation

Le flux Code d'autorisation permet de récupérer des jetons sur un canal secondaire plutôt que sur le canal frontal du navigateur. Le code d'autorisation octroyé prend en charge l'authentification du client. Voici le flux recommandé pour les applications natives telles que les applications mobiles et les formulaires Windows.

Étape 1 : Une application demande un code d'autorisation au serveur d'authentification.

GET https://<server>/AuthServices/Auth/connect/authorize?
response_type=code
&client_id=<client_id>
&redirect_uri=<your_app_callback_url>
&scope=openid profile athoc.iws.web.api offline_access
&state=<guid>&acr_values=tenant:<org_code>
&code_challenge=<ClientGenerated_CodeChallenge>
&code_challenge_method=S256

state
Il s'agit d'une valeur opaque que l'application ajoute à la demande initiale. Lors de l'authentification, l'application envoie ce paramètre dans la demande d'autorisation et le serveur d'autorisation renvoie ce paramètre non modifié dans la réponse. Cette valeur doit être utilisée par l'application pour empêcher les attaques CSRF (Cross-site Request Forgery). Cette valeur peut également être utilisée par l'application pour restaurer l'état précédent de l'application.

Pour plus d'informations sur le paramètre d'état, reportez-vous à :

https://auth0.com/docs/api-auth/tutorials/authorization-code-grant

https://auth0.com/docs/protocols/oauth2/oauth-state

code_challenge
: Le code_challenge est une chaine encodée en Base64-URL du hachage SHA256 du code_verifier. Votre application enregistre le code_verifier pour plus tard et envoie le code_challenge avec la demande d'autorisation à l'URL d'autorisation de votre serveur d'autorisation.

Pour plus d'informations sur le code_challenge, reportez-vous à :

https://developer.okta.com/authentication-guide/implementing-authentication/auth-code-pkce

Étape 2 : Le navigateur redirige l'utilisateur vers l'écran de connexion.

Le navigateur redirige l'utilisateur vers l'écran de connexion. Lors de la saisie des informations de connexion, si celles-ci sont valides, le navigateur dispose du code d'authentification dans l'URL. Si les informations de connexion ou le code d'organisation ne sont pas valides, le navigateur affiche le code d'état HTTP 400 Bad Request.

Étape 3 : Le client demande le jeton d'accès (access_token) sur la base du code d'authentification de l'étape 2.

POST https://<Server>/AuthServices/Auth/connect/token
{
     "grant_type":"authorization_code",
     "code":"<code>" //code returned in browser from 2nd Step
     "redirect_uri":"<your_app_callback_url>",
       "client_id":"<client_id>",
       "code_verifier":"<ClientGenerated_CodeVerifier>"
}

Étape 4 : Le serveur d'authentification envoie la réponse du jeton d'accès.

{
   "expires_in":3600,
   "token_type":"Bearer",
   "refresh_token":"ljiweoriwoer...",
   "access_token":"okljhgfdsighijuhdfgdkljhgdflkgjlkjdlfkgj..."
}

Section:

Authentification