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

$data = array(
'response_type' => 'code',
'client_id' => 'chemin_openid',
'state' => $oauth_state,
'scope' => 'openid profile',
);
$authorization_endpoint = 'https://oa.dnc.global/authorization';
$authorization_endpoint .= '?' . http_build_query($data);
header('Location: ' . $authorization_endpoint);
exit();

Télécharger

SPIP

include_spip('inc/headers');
$oauth_state = session_get('oauth_state');
$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";
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.