OpenID Connect OAuth Server dédié

Une fonction pour tout simplifier !

B. Degoy — 2017-12-16T09:45:00Z

Du côté d'une application cliente, utiliser l'authentification OAuth pour interroger une API HTTP REST peut se réduire à une simple fonction.

Nous sommes dans le cas du flux Autorisation via un code (Authorization Code Grant).

Le diagramme ci-contre donne une idée simplifiée de la suite des échanges entre les 3 pôles d'un flux de type Autorisation via un code. La fonction ci-dessous correspond à la ligne "Client App". Le rafraîchissement du jeton d'accès qui apparaît dans le code a été omis dans le diagramme pour simplifier. Cliquez sur l'image pour l'agrandir

Voici un exemple en PHP pour SPIP 3.1 :
SPIP

 'POST', 'datas' => array( 'grant_type' => 'refresh_token', 'refresh_token' => $_SESSION['oauth_refresh_token'], 'client_id' => 'chemindeleau', 'client_secret' => '01fc4587ab1c23ff456e448dab18327a', ), ); $url = "http://oa.dnc.global/oauth/token.php"; $refresh_response = recuperer_url($url,$options); $refresh_status = (int)$refresh_response['status']; if ( $refresh_status == 200 ) { // Enregistrer le jeton d'accès et recommencer $page = json_decode($refresh_response['page'], true); $_SESSION['oauth_access_token'] = $page['access_token']; return ProtectedApi_GET_auto ( $request); // réentrer } else // Demander une nouvelle authentification Authenticate(); } else return false; break; default : // Demander une nouvelle authentification Authenticate(); } return false; } } else { // Demander une nouvelle authentification Authenticate(); } } /** * Demander une nouvelle authentification au serveur OAuth */ function Authenticate() { // Sécurité : Générer un ID de session nouveau à chaque demande d'autorisation @session_regenerate_id(); // Dire à Callback où il faudra reprendre après authentification $_SESSION['oauth_again'] = $_SERVER['REQUEST_URI']; // Interroger Authorize $url = "https://oa.dnc.global/oauth/authorize.php?response_type=code&client_id=" . APPNAME . "&state=" . session_id(); redirige_par_entete($url); }

L'utilisation de la fonction est très simple.
La fonction retourne un objet JSON représentant la réponse, que l'on peut facilement transformer en Array PHP :

// Le nom de l'application cliente define ( 'APPNAME', 'testrpc3' ); // Requete $request = "https://r.dnc.global/http.api/collectionjson/gis/27"; // Afficher l'array obtenu echo print_r( json_decode( ProtectedApi_GET_auto ( $request ) ) , true );

Lancer un test

Dans ce test, les rôles sont les suivants :
– application cliente : chemindeleau,
– serveur de données protégées : API Rest de Radar,
– serveur d'authentification : oa.dnc.global,
– utilisateur final : vous.

Lancer le test

Vous devrez cliquer sur "Inscrivez-vous ici" pour être inscrit comme client final sur le serveur d'autorisation. Rappel : nous ne divulguons pas les E-mails.

Si vous ne voulez pas vous inscrire sur ce serveur en tant qu'utilisateur, vous pourrez utiliser les identifiants suivants :
E-mail or pseudo : bebert
Password : 012345678

OAuth 2.0 : Obtenir une autorisation pour l'application cliente

B. Degoy — 2017-01-12T20:18:00Z

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

https://oa.dnc.global/oauth/authorize.php
Le point d'extrémité d'autorisation est le point d'extrémité sur le serveur d'autorisation vers lequel l'application cliente redirige l'user-agent (en général un navigateur Web) pour obtenir une autorisation de la part de l'utilisateur final.

Forme de la demande d'autorisation

Voici un exemple en PHP avec SPIP :

SPIP

// Interroger Authorize include_spip('inc/headers'); $oauth_state = session_get('oauth_state'); $url = "http://oa.dnc.global/oauth/authorize.php?response_type=code& client_id=radar&state=$oauth_state"; redirige_par_entete($url);

Notes :
– Le paramètre state, mentionné comme facultatif dans la spécification d'Oauth, est obligatoire sur OAuthSD afin d'éviter une faille de sécurité bien connue.
– 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 (voir ci-après).
– 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.

A l'appel du Point d'extrémité d'autorisation :
– le serveur OAuth redirige l'user-agent vers la page d'authentification (on reste dans le domaine du serveur d'autorisation).
– le client s'authentifie dans cette page (donc sur le serveur d'authentification).
– le serveur poste le code d'autorisation au Point d'extrémité de redirection.

Voici un exemple de page d'authentification :

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. Cet URI est défini par l'auteur d'une application cliente quand il l'inscrit sur ce serveur. Voir : OAuth 2.0 : Lier une application cliente au serveur OAuthSD.

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.

Exemple de code pour le Point d'extrémité de redirection

B. Degoy — 2016-11-06T20:05:49Z

L'écriture du code pour traiter le retour de l'autorisation est la partie la plus importante de l'adaptation d'une application cliente en vue d'accéder à une ressource protégée par OAuth. Cependant, il est possible d'écrire ce code pour qu'il s'adapte à tous cas de figure et qu'il puisse s'intégrer à tout développement ultérieur. L'investissement en vaut la peine !

Nous fournissons ici le squelette d'un tel code, en PHP, pour le flux Autorisation via un code (Authorization Code Grant).

Tous les cas non conformes ne sont pas traités, mais cependant le code est fonctionnel.
PHP

 'authorization_code', 'code' => $sanitized_authcode, 'client_id' => 'XXXXXXX', 'client_secret' => 'XXXXXXXXXXXXXX', ); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $datas); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HEADER, false); curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); $result_json = curl_exec($ch); $result = json_decode($result_json, true); $http_code = curl_getinfo( $ch, CURLINFO_HTTP_CODE ); curl_close($ch); switch( (int)$http_code ) { case 200 : if ( $result['access_token'] ) { $token = $result['access_token']; $sanitized_token = preg_replace('/[^a-f0-9"\']/', '', $token); if ( $sanitized_token === $token ) { $jeton = $token; } else { // Jeton d'accès corrompu } } else { // Application non autorisée } if ( $result['refresh_token'] ) { $refresh_token = $result['refresh_token']; $sanitized_rtoken = preg_replace('/[^a-f0-9"\']/', '', $refresh_token); if ( $sanitized_rtoken === $refresh_token ) { $rejeton = $refresh_token; } else { // Jeton de rafraîchissement corrompu } } else { // Application non autorisée } if ( !empty($jeton) AND !empty($rejeton) ) { // Ici, il serait bon de vérifier le jeton, par introspection par exemple. ... // Succès, mémoriser les jetons dans la session de l'application $_SESSION['oauth_access_token'] = $jeton; $_SESSION['oauth_refresh_token'] = $rejeton; if ( $oauth_again = $_SESSION['oauth_again'] ) { // Reprendre où nous en étions avant l'interruption header('Location: ' . $oauth_again ); exit; } } break; case 401 : // Accès non autorisé : problème avec CORS ? break; case 405 : // Requête invalide break; case 400 : // URL non trouvée ou Accès non autorisé default: break; } if ( empty($jeton) ) { // Lire l'erreur if ( !is_null( $result ) ) { $msg = json_decode( $res, true ); echo $msg['error']; //DEBUG } } } else { // Code d'autorisation corrompu } ?>

Ceci n'est qu'un exemple très incomplet. Il est important de noter que le jeton ne sert à rien, puisque nous ne le validons pas. La seule chose que nous apprend cette procédure est que l'application est autorisée, à condition toutefois que la réponse ne soit pas falsifiée. La sécurité repose sur l'intégrité de la liaison application-serveur.