OpenID Connect : Obtenir une autorisation pour l’application cliente

, par B. Degoy

Dans le cadre du flux Autorisation avec Code (Authorization Code Flow) l’user-agent (en général un navigateur Web) de l’utilisateur final est redirigé sur le Point d’extrémité d’autorisation (Authorization Endpoint), pour permettre à l’utilisateur de s’identifier et d’accorder des autorisations à l’application cliente.
En cas de succès, l’user-agent sera redirigé sur le Point d’extrémité Token avec un code d’autorisation.

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

https://oa.dnc.global/authorize

Forme de la demande d’autorisation

Voici des exemples :

PHP

    $data = array(
        'response_type' => 'code',
        'client_id' => 'chemin_openid',
        'state' =>  getRandomBytes(),
        'scope' => 'openid profile',
    );

$authorization_endpoint = 'https://oa.dnc.global/authorization';

$authorization_endpoint .= '?' . http_build_query($data);
    header('Location: ' . $authorization_endpoint);
    exit();

SPIP

   $state = getRandomBytes();          
   $state = substr($state,2,16); 
   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).