Point d’extrémité d’autorisation (Authorization Endpoint)
https://oa.dnc.global/authorize
Forme de la demande d’autorisation
Voici des exemples :
PHP
- 'response_type' => 'code',
- 'client_id' => 'chemin_openid',
- 'state' => getRandomBytes(),
- 'scope' => 'openid profile',
- );
- $authorization_endpoint = 'https://oa.dnc.global/authorization';
SPIP
- $state = getRandomBytes();
- session_set('state', $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=$state";
- redirige_par_entete($url);
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. C’est d’ailleurs préférable en termes de sécurité.
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, comme un identificateur de session. 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 envoie à l’user-agent 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.
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
Se reporter à : API OpenID Connect : Point d’extrémité d’autorisation (Authorization Endpoint).