Accueil > OpenID Connect OAuth Serveur dédié > Développer > OpenID Connect > API OpenID Connect : Point d’extrémité d’autorisation (Authorization (...)

API OpenID Connect : Point d’extrémité d’autorisation (Authorization Endpoint)

C’est le point d’extrémité sur le serveur d’autorisation auquel l’user-agent (en général un navigateur Web) de l’utilisateur final est redirigé, pour lui permettre de s’identifier et d’accorder des autorisations à l’application cliente.
Dans le cas du flux d’autorisation avec code (Authorization code flow), le contrôleur Authorize redirige l’user-agent sur le point d’extrémité Token avec un code d’autorisation.
Le flux implicite permet d’obtenir directement les jetons.

Point d’extrémité d’autorisation (Authorization Endpoint)

https://oa.dnc.global/authorize

Forme de la demande d’autorisation

Exemples d’appel Authorize :

PHP

  1.     $data = array(
  2.         'response_type' => 'code',
  3.         'client_id' => 'chemin_openid',
  4.         'state' =>  $oauth_state,
  5.         'scope' => 'openid profile',
  6.     );
  7.  
  8. $authorization_endpoint = 'https://oa.dnc.global/authorization';
  9.  
  10. $authorization_endpoint .= '?' . http_build_query($data);
  11.     header('Location: ' . $authorization_endpoint);
  12.     exit();

Télécharger

SPIP

  1.     include_spip('inc/headers');
  2.    
  3.     $oauth_state = session_get('oauth_state');
  4.     $url = "http://oa.dnc.global/authorize?response_type=code&client_id=chemin_openid&scope=openid profile&redirect_uri=http://chemindeleau.com/callback_openid.php&state=$oauth_state";
  5.    
  6. redirige_par_entete($url);

Télécharger

Notes :
- Pour obtenir un jeton d’identité, le scope doit comporter "openid". Dans le cas contraire, la réponse sera identique à celle du protocole OAuth 2.0, et ne comprendra donc que le jeton d’accès.
- Pour obtenir un jeton de rafraîchissement (Refresh Token), le scope doit comporter "offline_access".
- Bien que la "norme" indique que le paramètre redirect_uri est obligatoire, il peut être omis si l’application cliente a été inscrite avec une seule adresse de retour.
Bien que la norme indique que le paramètre state est facultatif, il est essentiel pour la sécurité de le présenter dans la demande.
- si l’application cliente a été inscrite avec plusieurs adresses de retour, le paramètre redirect_uri est obligatoire, et doit représenter l’une d’elles.
- Il est possible de rajouter à l’URL tout paramètre utile. Ceux-ci seront retransmis dans le corps de la réponse, de façon quasi intégrale.
- Avant qu’elle puisse interagir dans un flux OpenID Connect, l’auteur doit inscrire l’application cliente sur le serveur OAuthSD avec les paramètres attendus par OpenID Connect.
- Il est de la responsabilité de l’application cliente d’assurer la bonne forme et la sécurité des valeurs transmises par les paramètres d’URL.

Authentification de l’utilisateur final

A l’appel du Point d’extrémité d’autorisation :
- le serveur OAuthSD redirige l’user-agent vers la page d’authentification (on reste dans le domaine du serveur d’autorisation).
- l’utilisateur final s’authentifie dans cette page (les identifiants sont donc confinés au niveau du serveur).
- le serveur poste le code d’autorisation au Point d’extrémité de redirection.

Voici un exemple de page d’authentification :

http://oa.dnc.global/authorize?response_type=code&client_id=chemin_openid&redirect_uri=http://chemindeleau.com/callback_openid.php&state=4f67ae45bd188aa3

Notes :
- si l’on souhaite afficher la page d’authentification dans le contexte visuel de l’application cliente, il faut le faire dans un iFrame, plutôt que par une insertion en script côté client (Popup Javascript), afin de ne pas compromettre les identifiants de l’utilisateur. Cependant, il convient d’appliquer les bonnes pratiques de sécurité relatives à la mise en oeuvre des iFrame.

Retour à l’application cliente

En cas de succès, le serveur redirige le navigateur sur le point d’extrémité de redirection dans l’application cliente ( par entête HTTP code 302 ). Cet URI est défini par l’auteur d’une application cliente quand il l’inscrit sur ce serveur. Voir : OpenID Connect : Lier une application cliente au serveur OAuthSD.

Les paramètres code et state sont passés dans l’URL. Exemple :

http://chemindeleau.com/callback_openid.php?code=3159339c2f1326f9fa128e161b8387feca690b65&state=98b3027139f7cb3be4a885d7c81b41bb

Il est de la responsabilité de l’application cliente d’assurer sa sécurité vis-à-vis des valeurs transmises par les paramètres d’URL.

Situations d’erreur

En cas d’échec le corps de la réponse contient :

index type valeur
page JSON Array error : titre de l’erreur,
error_description : description de l’erreur

La réponse HTTP ainsi que les valeurs de error et error_description sont données par le tableau suivant :

Réponse error
titre de l’erreur
error_description
description de l’erreur
Explication
302 login required The user must log in Le jeton d’accès n’existe pas ou n’est plus valide. Cette réponse n’apparait que si login=’none’ car, dans les autres cas, le serveur OAuthSD prend à sa charge le dialogue de connexion. Cette erreur pourra apparaître en cas d’échecs successifs.
302 interaction_required The user must grant access to your application Le serveur a déterminé que des scopes doivent être approuvés par l’utilisateur final. Il y a peu de chance que cette erreur apparaisse avec OAuthSD, car la situation est gérée au niveau du contrôleur Authorize qui prend à sa charge le formulaire d’acceptation.
302 consent_required The user denied access to your application L’utilisateur final a explicitement refusé la demande d’autorisation qui lui a été présentée.
400 invalid_client No client id supplied Le paramètre client_id est obligatoire.
400 invalid_client The client id supplied is invalid Le paramètre client_id doit être identique à ce qui a été inscrit pour l’application.
400 invalid_uri The redirect URI must not contain a fragment
400 invalid_uri No redirect URI was supplied or stored
400 invalid_uri A redirect URI must be supplied when multiple redirect URIs are registered
400 redirect_uri_mismatch The redirect URI provided is missing or does not match Le paramètre redirect_uri doit être identique à ce qui a été inscrit pour l’application.
400 invalid_uri The redirect URI must not contain a fragment
400 missing_code_challenge This application requires you provide a PKCE code challenge Voir Clé de vérification pour l’échange de code (PKCE)
401 not_allowed L’utilisateur final a probablement fait une erreur dans ses identifiants. Recommencer.
401 malformed_identifier L’utilisateur final a fourni un identifiant (e-mail ou pseudo) mal formé. Recommencer.
401 malformed_email Un E-mail est requis en guise d’identifiant de l’utilisateur final. L’utilisateur final a probablement fait une erreur. Recommencer.
403 consent_required The user denied access to your application L’utilisateur a refusé son accord ou a abandonné l’authentification.
403 forbidden Probablement une attaque de type "Man in the middle". Ne pas réagir.

Si le serveur retourne une erreur 401, il est de la responsabilité de l’application cliente de présenter un message d’erreur à l’utilisateur final et de recommencer (ou non) l’authentification. Dans tous les autres cas d’erreur, l’application cliente ne devrait pas redemander l’authentification avant d’avoir identifié l’erreur au niveau technique.

Dans certains cas, la redirection peut être effectuée, le corps de la réponse contenant un message d’erreur :

error
titre de l’erreur
error_description
description de l’erreur
Explication
invalid_request Invalid or missing response type response_type doit être "code"
unauthorized_client The grant type is unauthorized for this client_id Vérifiez que l’application a bien été inscrite avec le type d’autorisation Authorization_code
redirect_uri_mismatch The redirect URI is mandatory and was not supplied Le paramètre redirect_uri doit figurer dans la requête.

Réponse sans redirection

Un certain nombre d’erreurs provoquent une réponse HTTP directe (sans rediriger le navigateur sur le point d’extrémité de redirection). Il s’agit d’anomalies dans la requête, traduisant une tentative d’intrusion. Le code d’erreur HTTP est le plus souvent 400 ’Bad Request’ ou 403 ’Forbidden’.
Ce type d’erreur ne devrait jamais se produire avec une application cliente autorisée. Le concepteur d’une application cliente n’a pas à s’en préoccuper.