OpenID Connect OAuth Server dédié

Lien de (re)connexion

DnC — 2021-04-02T15:30:00Z

Il peut être utile de permettre à un utilisateur de se connecter sans passer par une procédure d'identification. Par exemple lorsque le login ou le mot de passe a été perdu et pour éviter la fastidieuse procédure de récupération du "mot de passe oublié".

Nous décrivons ici comment créer un lien de reconnexion qui pourra, par exemple, être adressé à l'utilisateur dans un e-mail.

Plutôt que faire figurer le jeton d'identité dans le lien, qui peut être trop grand pour être passé en URL, on prendra l'ID Token dans une table où il se trouve indexé par son hash, et ce sera cette valeur qui sera passée dans le lien de reconnexion.

En tête de chaque page pouvant être appelée avec reconnexion, on appellera avec :

{fond=inclure/autoconnect}{env}>

la noisette suivante :

SPIP

[(#REM) 150b Autoconnect : connexion OIDC avec la méthode id_token_hint
Remplace la noisette identification pour assurer l'authentification avec l'ID Token passé par le paramètre d'URL token
auteur : B.Degoy i-Tego
licence : GNU/GPL
]
[(#ENV{token}|autoconnect{#SELF}|non)
[(#SESSION{id_auteur}|non)
<:oauth:vous_devez_vous_identifier:>.
<:oauth:vous_pas_compte:> #ENV{lang}"><:oauth:creer_compte_auteur:>
#LOGIN_PUBLIC
]
]

Télécharger

Voici le code du filtre autoconnect :

PHP SPIP

/**
* Autoconnect pour DnC SaaS (base SPIP)
* @auteur : B.Degoy i-Tego
* SPIP, Systeme de publication pour l'internet
* Copyright (c) 2001-2020
* Arnaud Martin, Antoine Pitrou, Philippe Riviere, Emmanuel Saint-James
* Ce programme est un logiciel libre distribue sous licence GNU/GPL.
* Pour plus de details voir le fichier COPYING.txt ou l'aide en ligne.
*/
//[dnc150b]
/**
* Lancer une (re)connexion par la méthode OIDC id_token_hint avec le token fourni.
* Ceci suppose que la dernière connexion de l'utilisateur ait été enregistrée dans la table jwt.
* La table jwt est indexée par le hash de l'ID Token.
* C'est cette valeur, plus courte que l'ID token lui-même, qui est passée dans l'URL d'autoconnexion.
*
* @param mixed $idt_hash : le hash de l'ID Token
*/
function filtre_autoconnect_dist( $idt_hash, $url=null ) {
//DebugBreak("435347910947900005@127.0.0.1;d=1"); //DEBUG
// Récupérer l'ID Token et le client avec idt_hash
include_spip('base/abstract_sql');
$res = sql_fetsel('client_id, id_token', 'spip_jwt', 'idt_hash=' . sql_quote($idt_hash));
if ( ! is_null($res) ) {
// Générer un state
include_spip('inc/session');
$state = md5($idt_hash);
$state= substr($state, 0, 16);
session_set('state', $state);
// Page à laquelle rediriger après l'authentification.
if ( empty($url) ) $url = './';
$url = parametre_url($url, 'token', ''); // sans le token évidemment (car il ne sera plus valide après la (re)connexion.
session_set('caller', $url); // voir plugin oidcclient : oidc_setps.php.
// lancer une (re)connexion par la méthode OIDC id_token_hint
$redirect = '/authorize';
$redirect = parametre_url($redirect, 'response_type', 'code', '&');
$redirect = parametre_url($redirect, 'scope', 'openid sli', '&');
$redirect = parametre_url($redirect, 'prompt', 'none', '&');
$redirect = parametre_url($redirect, 'client_id', $res['client_id'], '&');
$redirect = parametre_url($redirect, 'state', $state, '&');
$redirect = parametre_url($redirect, 'url', $url, '&');
$redirect = parametre_url($redirect, 'id_token_hint', $res['id_token'], '&');
include_spip('inc/headers');
redirige_par_entete($redirect);
} else {
// idt_hash non valide ou erreur plus générale.
return ""; // pour faire échouer le test
}
}

Télécharger

Cette procédure de reconnexion revient exactement à une nouvelle connexion de l'utilisateur. Cela veut dire en particulier que le cookie SLI et les jetons seront régénérés.

Comme le jeton d'identité change, son hash change et il en résulte que le jeton passé dans le lien de reconnexion est à usage unique.

id_token_hint : ré-authentification silencieuse du sujet avec l'ID Token

DnC — 2019-07-12T12:30:05Z

L'authentification du sujet (subject, sub) avec l'ID Token est une option du flux de code OpenID Connect Authorization.
Pour passer la certification OpenID Connect, il est nécessaire de terminer le test "OP-Req-id_token_hint".
La bibliothèque oauth2-server-php de Brent Shaffer ne traite pas id_token_hint. OAuthSD devra donc s'en occuper.

Le cas d'utilisation consiste à appeler Authorize à l'aide de prompt = 'none' et à transmettre l'ID Token par le paramètre id_token_hint.

La spécification stipule :

id_token_hint
OPTIONNEL. Le jeton ID précédemment émis par le serveur d'autorisations est transmis en tant qu'identifiant de la session d'authentification actuelle ou passée de l'utilisateur final avec le client. Si l'utilisateur final identifié par le jeton ID est connecté ou est connecté par la requête, le serveur d'autorisations renvoie une réponse positive. sinon, il DEVRAIT retourner une erreur, telle que login_required. ... Le serveur d'autorisation n'a pas besoin d'être répertorié en tant qu'audience du jeton ID lorsqu'il est utilisé en tant que valeur id_token_hint.

Comment OAuthSD Implémente le traitement id_token_hint

Si l'appel à Authorize inclut le paramètre id_token_hint, nous vérifierons la signature du Jeton d'Identité JWT. Si Ok, nous adopterons la valeur de la déclaration sub pour définir l'identifiant de l'utilisateur final (user_id) et nous continuerons normalement avec le traitement de prompt = 'none'.

L'expression "ou est connecté par la requête" peut couvrir un mécanisme tel que la réauthentification silencieuse (SRA). C'est ce que OAuthSD permet de faire : le processus revient alors à étendre la session OIDC, c'est à dire rafraîchir le cookie SLI, que l'utilisateur soit connecté ou non.
Le contrôleur authorize répondra avec un code d'autorisation, et l'application redemandera les jetons, ce qui provoquera le rafraîchissement du jeton d'accès.
Ainsi, l'utilisateur sera (re)connecté, vu du serveur, pour la pleine durée de vie du nouveau jeton d'accès. Nous n'accorderons pas beaucoup de confiance à cette méthode, aussi l'acr_value sera fixé à 1.

L'administrateur peut contrôler le processus avec les constantes de configuration REAUTHENTICATE_BY_ID_TOKEN et DO_SRA_ON_ID_TOKEN (définies par défaut sur true).

Remarque de sécurité

Lorsque l'on fait une authentification avec prompt = 'none', on devrait toujours y associer le paramètre id_token_hint. Plus exactement, interroger Authorize avec prompt = 'none' sans id_token_hint ne peut être considéré comme une authentification, mais comme une simple information sur la connexion de l'utilisateur déclaré.

Notes :
Si user_id est forcé par l'enregistrement du client, la déclaration subject du jeton d'identité doit être identique, sinon le processus échouera.
login = "none" exclut l'invite de l'utilisateur. L'expression « ou est connecté par la demande » peut couvrir un mécanisme tel que la ré-authentification silencieuse (SRA). C'est ce que OAuthSD permet de faire.

Voyez également :
OpenID Connect : SSO, management de session etc..

[dnc68]

OpenID Connect : Exemples complets du flux d'Autorisation via un code puis requête UserInfo

DnC — 2017-04-20T20:30:00Z

Les scripts testopenid testent le flux d'Autorisation via un code (Authorization Code Flow), et enchaînent sur une demande UserInfo, en ne laissant passer aucune erreur : tous les cas non conformes répertoriés dans cette documentation donneront lieu à l'affichage d'un message d'erreur.

Les deux méthodes de validation du JWT sont illustrées : Validation locale, Introspection.

Ces scripts ne sont pas conçu pour une application en production. Cependant, ils fournissent un flux complet que vous pourrez adapter au besoin de votre application cliente. En particulier, il serait opportun d'utiliser les fonctions d'affichage et de gestion des erreurs du système de l'application cliente.

Notez que ces scripts jouent le rôle de Point d'extrémité de redirection, ou URI de retour à l'application cliente (Redirection Endpoint). Voyez : OAuth 2.0 : Points d'extrémité.

Première version : Validation locale du JWT

La vérification du jeton JWT est effectuée localement par la fonction decode_jwt(), qui est décrite dans cet article : JSON Web Token (JWT).

PHP

/*
testopenid3.php
Verbose Test of OpenID Connect Authorization Code Flow
This code is meant for testing, not for production !
At the authentification step, if you don't want to create an account
on OAuthSD, use this credentials :
login = bebert
password = 012345678
Author :
Bertrand Degoy https://degoy.com
Credits :
bschaffer https://github.com/bshaffer/oauth2-server-php
Licence : MIT licence
Copyright (c) 2016 - DnC
*/
//***** Configuration *****
/* Client's Public Key
Warning : no double-quote, no indent!
*/
define ('PUBLIC_KEY',
'-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2dCHybdu/1pDk5BHSxMA
nMGygm8lm6s2hnru3GPH2JyMxrd92dC7TljI21P+egsnmjsUzaS1IWZPvIFvEOwO
5wP8gFyNm8fFkXSmrAEHXLFJ6WufF+f5Fg3pU5GDPjT5Z7ccWab5NM9w7ec433J1
XtePh2QjUbibu4rpwYh8ADODAJkyIRMhhYXqK0n8GgojkcgEZ172sB/NdbcNALPy
Qg0lMd3/AKxavTSSm9LslEyP+ZwBvTENzhoeQV2V7ZQ5xIZs6VBgrnsnYbgfbdQ+
Dbk2FRbtB2+g4rKbN04JheaZyFORseoigVJ6asQ5lUS/3cMIUj2C+VBj4xAyXp00
TMH8GtiGIQkVYjBd/Lsza11YwBOA8YYvDnTs/kzy9CqHjETdIHUlNqeaFbHSYTST
rUl9QxBN+JAVGs9YY9MWoiVsGex4MsTwf3PanKIlavKXeFSwppwMMvmdt+yrGraH
UKv5QP5NMbOu6/BghbuQZP4MoUnRxQxt8PN2e5M2b358C3tctgRQhRGBWaYw8B5J
/drz5VA8s14NkG162lBW7PLYhLqm8u2hpqIlOCVndwW2W+bCkXrfjj3jBHe4yauQ
vyQWcv3KaBV2HsUoY2sCAaC5nB46SV0UkAycX8xyqOsGJA64m2S+ntOQkB9R2x2y
4DjfJHTRTe2uXsaiYFahoLECAwEAAQ==
-----END PUBLIC KEY-----
');
$client_id = 'testopenid';
$client_secret = 'thesecret';
$authorization_endpoint = 'https://oa.dnc.global/authorize';
$token_endpoint = 'https://oa.dnc.global/token';
$userinfo_endpoint = 'https://oa.dnc.global/userinfo';
//*** End of configuration ***
ini_set('display_errors', 1);
// Set session
session_save_path('/home/oadnc/sessions_oauthsd');
session_name('oauthsd');
session_start();
if ( !isset($_GET['error']) ) {
if ( isset($_GET['code']) ) {
if ( isset($_GET['state']) ) {
// Check state
if ( $_GET['state'] == $_SESSION['state'] ) {
// Step 2. Token request
$code = $_GET['code'];
$data = array(
'grant_type' => 'authorization_code',
'code' => $code,
);
$h = curl_init($token_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_USERPWD, "{$client_id}:{$client_secret}");
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_HTTPHEADER,
array('Content-Type: application/x-www-form-urlencoded'));
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data));
//curl_setopt($h, CURLOPT_SSL_VERIFYPEER, false);
$res = curl_exec($h);
if ($res) {
curl_close($h);
$res = json_decode($res, true);
if ( empty($res['error'] ) ) {
// Validate signed JWT token using client's public key
if ( $payload = decode_jwt($res['id_token'],
PUBLIC_KEY, 'RS256') ) {
// If Token Response is valid goto step 3
// Step 3. Get UserInfo
$access_token = $res['access_token'];
/* Auth Header Methode
$headr = array();
$headr[] = 'Authorization: Bearer ' . $access_token;
$h = curl_init();
curl_setopt($h, CURLOPT_URL, $userinfo_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_HTTPHEADER, $headr);
//curl_setopt($h, CURLOPT_SSL_VERIFYPEER, false);
//*/
//* Post Methode
$data2 = array(
'access_token' => $access_token,
'state' => $state,
);
$h = curl_init($userinfo_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_HTTPHEADER,
array('Content-Type:
application/x-www-form-urlencoded'));
curl_setopt($h, CURLOPT_POSTFIELDS,
http_build_query($data2));
//*/
$res = curl_exec($h);
if ( $res ) {
curl_close($h);
$res = json_decode($res, true);
if ( empty($res['error'] ) ) {
// Check User ID
if ( $payload['sub'] == $res['sub'] ) {
// Everithing Ok !
echo "UserInfo Response:\n";
print_r($res);
} else
// User of ID Token doesn't match UserInfo's one
exit('User mismatch, got : ' . $res['sub']);
} else
// Token request error
exit ('UserInfo Request error : ' . $res['error'] . ' : '
. $res['error_description']);
} else {
// Curl error during UserInfo request
exit('UserInfo Request error : ' . curl_error($h));
curl_close($h);
}
} else
// Invalid id_token
exit('Error : Invalid ID Token');
} else {
// Token request error
exit ('Token request error : ' . $res['error'] . ' : '
. $res['error_description']);
}
} else {
// Curl error during Token request
exit('Token Request error : ' . curl_error($h));
curl_close($h);
}
} else
// Wrong State
exit("Authorization error : incoherent State");
} else
// Missing State
exit("Authorization error : missing State");
} else {
// Step 1. Authorization Code request
@session_regenerate_id();
$state = session_id();
$_SESSION['state'] = $state;
$data = array(
'response_type' => 'code',
'client_id' => $client_id,
'scope' => 'openid profile',
'state' => $state,
);
$authorization_endpoint .= '?' . http_build_query($data);
header('Location: ' . $authorization_endpoint);
exit();
}
} else {
// Authorization error
exit("Authorization error : {$_GET['error']} : {$_GET['error_description']}");
}

Télécharger

Notons que, dans cet exemple, nous avons intégré la clé publique dans le code. Une alternative consiste à se la procurer auprès d'AuthSD, voyez : API OpenId Connect : Point d'extrémité d'informations sur les clefs (Keys Endpoint). Mais la meilleure pratique est de valider le jeton par introspection.

Lancer le script : https://oa.dnc.global/oidc/tests/te...

Lors de la demande de vos login et mot de passe, 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

Voici la page de login générée par le serveur OAuthSD :

A propos du scope sli : vous noterez que le contrôleur Authorize est appelé avec le scope sli, alors que ce n'est pas le cas dans l'exemple suivant. Cela permet d'illustrer le fonctionnement de la Connexion unique (Single Login In, SLI).

Deuxième version : Validation du JWT par Introspection

La vérification du jeton JWT est effectuée par la méthode décrite dans cet article : API Open ID Connect : Introspection (Introspection Endpoint).

PHP

/*
testopenid4.php
Verbose Test of OpenID Connect JWT Introspection
This code is meant for testing, not for production !
For the authentification step, if you don't want to create an account
on OAuthSD, use this credentials :
login = bebert
password = 012345678
Author :
Bertrand Degoy https://degoy.com
Credits :
bschaffer https://github.com/bshaffer/oauth2-server-php
Licence : MIT licence
Copyright (c) 2016 - DnC
*/
$client_id = 'testopenid4';
$client_secret = 'thesecret';
$authorization_endpoint = 'https://oa.dnc.global/authorize';
$token_endpoint = 'https://oa.dnc.global/token';
$introspection_endpoint = 'https://oa.dnc.global/introspect';
$userinfo_endpoint = 'https://oa.dnc.global/userinfo';
//*** End of configuration ***
ini_set('display_errors', 1);
// Set session
session_save_path('/home/oadnc/sessions_oauthsd');
session_name('oauthsd');
session_start();
if ( !isset($_GET['error']) ) {
if ( isset($_GET['code']) ) {
if ( isset($_GET['state']) ) {
// Check state
if ( $_GET['state'] == $_SESSION['state'] ) {
// Step 2. Token request
$code = $_GET['code'];
$data = array(
'grant_type' => 'authorization_code',
'code' => $code,
);
$h = curl_init($token_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_USERPWD, "{$client_id}:{$client_secret}");
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_HTTPHEADER, array('Content-Type:
application/x-www-form-urlencoded'));
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data));
//curl_setopt($h, CURLOPT_SSL_VERIFYPEER, false);
$res = curl_exec($h);
if ( is_array(json_decode($res, true) ) ) {
curl_close($h);
$res = json_decode($res, true);
$access_token = $res['access_token'];
if ( empty($res['error'] ) ) {
// Validate signed JWT token using introspection
//* Post Methode
$data1 = array(
'token' => $res['id_token'],
);
$h = curl_init($introspection_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_HTTPHEADER, array('Content-Type:
application/x-www-form-urlencoded'));
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data1));
//*/
$res = curl_exec($h);
if ( is_array(json_decode($res, true) ) ) {
curl_close($h);
$jwt = json_decode($res, true);
if ( empty($jwt['error'] ) ) {
if ( $jwt['active'] == 'true' ) {
// If Token Response is valid goto step 3
// Step 3. Get UserInfo
/* Auth Header Methode
$headr = array();
$headr[] = 'Authorization: Bearer ' . $access_token;
$h = curl_init();
curl_setopt($h, CURLOPT_URL, $userinfo_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_HTTPHEADER, $headr);
//curl_setopt($h, CURLOPT_SSL_VERIFYPEER, false);
//*/
//* Post Methode
$data2 = array(
'access_token' => $access_token,
);
$h = curl_init($userinfo_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_HTTPHEADER, array('Content-Type:
application/x-www-form-urlencoded'));
curl_setopt($h, CURLOPT_POSTFIELDS,
http_build_query($data2));
//*/
$res = curl_exec($h);
if ( is_array(json_decode($res, true) ) ) {
curl_close($h);
$res = json_decode($res, true);
if ( empty($res['error'] ) ) {
// Check User ID
if ( $jwt['sub'] == $res['sub'] ) {
// Everithing Ok !
echo "UserInfo Response:\n";
print_r($res);
} else
// User of ID Token doesn't match UserInfo's one
exit('User mismatch, got : ' . $res['sub']);
} else
// Token request error
exit ('UserInfo Request error : ' . $res['error'] . ' : '
. $res['error_description']);
} else {
if ( !empty($res) ) {
// script error ?
exit ('UserInfo script error : ' . $res);
} else {
// Curl error during UserInfo request
$error = curl_error($h);
curl_close($h);
exit ('UserInfo request Curl error : ' . $error );
}
}
} else
// JWT is inactive
exit('Error : Invactive ID Token');
} else
// Invalid id_token
exit('Error : Invalid ID Token');
} else {
if ( !empty($res) ) {
// script error ?
exit ('Introspection script error : ' . $res);
} else {
// Curl error during Introspection request
$error = curl_error($h);
curl_close($h);
exit ('Introspection request Curl error : ' . $error );
}
}
} else {
// Token request error
exit ('Token request error : ' . $res['error'] . ' : '
. $res['error_description']);
}
} else {
if ( !empty($res) ) {
// script error ?
exit ('Token script error : ' . $res);
} else {
// Curl error during Token request
$error = curl_error($h);
curl_close($h);
exit ('Token request Curl error : ' . $error );
}
}
} else
// Wrong State
exit("Authorization error : incoherent State");
} else
// Missing State
exit("Authorization error : missing State");
} else {
// Step 1. Authorization Code request
@session_regenerate_id();
$state = session_id();
$_SESSION['state'] = $state;
$data = array(
'response_type' => 'code',
'client_id' => $client_id,
'scope' => 'openid profile sli',
'state' => $state,
);
$authorization_endpoint .= '?' . http_build_query($data);
header('Location: ' . $authorization_endpoint);
exit();
}
} else {
// Authorization error
exit("Authorization error : {$_GET['error']} : {$_GET['error_description']}");
}
?>

Télécharger

Lancer le script : https://oa.dnc.global/oidc/tests/te...

OpenID Connect : Obtenir les jetons d'accès

DnC — 2016-12-31T14:08:51Z

Nous sommes dans le cas d'un flux d'Autorisation via un code (Authorization Code).

L'application cliente doit disposer d'un jeton d'accès pour obtenir des données protégées de la part d'un serveur de ressources. Le code nécessaire est entièrement à la charge de l'auteur de l'application cliente, en réaction à la redirection sur l'URI du point d'extrémité de redirection.

Pour obtenir les jetons d'accès, une application cliente s'adresse au point d'extrémité token avec le code obtenu dans la phase d'autorisation.

Point d'extrémité de jeton (Token Endpoint)

https://oa.dnc.global/token

Plus de détails : API OpenID Connect : Point d'extrémité d'autorisation (Authorization Endpoint).

Le point d'extrémité de jeton est le point d'extrémité sur le serveur d'autorisation auquel s'adresse l'application cliente avec le code d'autorisation.

Forme de la demande de jeton d'accès

La demande ne doit être effectuée que par la méthode POST.

Pour l'authentification de l'application cliente auprès du serveur d'autorisation, OAuthSD impose la méthode client_secret_basic. L'authentification est donc effectuée en utilisant l'authentification HTTP Basic (cf. section 2.3.1 de OAuth 2.0 [RFC6749]). Les identifiants client_id et client_secret sont ceux qui ont été définis lors de l'inscription de l'application cliente sur le serveur.

Les paramètres suivants sont postés :
grant_type : Type de flux d'autorisation, doit être "authorization_code".
code : le code d'autorisation reçu.
redirect_uri : (optionnel) l'adresse de retour à l'application cliente.

redirect_uri est utile lorsque plusieurs adresses de retour ont été enregistrées sur le serveur pour une même application cliente. Cet URI doit donc exactement correspondre à l'une d'elles.

Réponse du serveur

En cas de succès, le serveur retourne une réponse HTTP 200. Le corps de la réponse contient :

index	type	valeur
page	JSON array	access_token : (string) jeton d'accès OAuth 2.0 expires_in : (long) durée de vie en secondes token_type : (string) "Bearer" scope : (string) "openid ... " id_token : (string) jeton d'identification (JWT)

Le Header comporte, comme il se doit, la directive 'Cache-Control : no-cache, no-store'.

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 sont décrites ici : API OpenID Connect : Point d'extrémité de jeton (Token Endpoint).

Demande du jeton de rafraîchissement

OpenID Connect ne retourne un jeton de rafraîchissement (Refresh Token), conjointement au jeton d'accès, que si le scope "offline_access" a été inclus dans la requête et accepté, ce qui ne se produira qu'avec le flux d'Autorisation via un code (Authorization Code Grant).

Exemples de code

Données de la requête :
$authcode est le code d'autorisation obtenu à l'étape précédente et transmis à la page de CallBack
$client_id, $client_secret : Comme indiqué lors de l'inscription de l'application cliente sur le serveur d'autorisation.

PHP

// Demander un jeton d'accès pour l'application
$url = 'http://oa.dnc.global/token';
$datas = array(
'grant_type' => 'authorization_code',
'code' => $authcode,
'redirect_uri' => 'http://chemindeleau.com/callback_openid.php',
'client_id' => 'chemin_openid',
'client_secret' => '01fc458',
);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/x-www-form-urlencoded'));
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($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);
curl_close($ch);
$result = json_decode($result_json, true);
$access_token = $result['access_token']; // Access Token
$id_token = $result['id_token']; // ID Token (JWT)

Télécharger

L'authentification peut également être passée dans le Header comme ceci :

$datas = array(
'grant_type' => 'authorization_code',
'code' => $sanitized_authcode,
'redirect_uri' => 'http://chemindeleau.com/callback_openid.php',
);
$client_id = 'chemin_openid';
$client_secret = '01fc458';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_USERPWD, "{$client_id}:{$client_secret}");
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/x-www-form-urlencoded'));
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($datas));
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

Télécharger

SPIP

$url = 'http://oa.dnc.global/oauth/token.php';
$options = array(
'method' => 'POST',
'datas' => array(
'grant_type' => 'authorization_code',
'code' => $authcode,
'redirect_uri' => 'http://chemindeleau.com/callback_openid.php',
'client_id' => 'chemin_openid',
'client_secret' => '01fc458',
)
);
$res = recuperer_url($url, $options);
$page = json_decode($res['page'], true);
$token = $page['access_token'];
$id_token = $page['id_token'];

Télécharger

OpenID Connect : Obtenir une autorisation pour l'application cliente

DnC — 2016-12-22T14:15:35Z

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();

Télécharger

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);

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. 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).

Authentification utilisant le flux de code d'autorisation OpenID Connect

DnC — 2016-12-21T10:46:21Z

Cette section explique comment effectuer l'authentification à l'aide du Flux du code d'autorisation.

La suite de cet article est une traduction d'un extrait de OpenID Connect Core 1.0 avec nos commentaires.

3.1. Authentification utilisant le flux de code d'autorisation OpenID Connect (Authorization Code Flow).

Cette section explique comment effectuer l'authentification à l'aide du Flux du code d'autorisation [1].

Lorsque vous utilisez le Flux du code d'autorisation, tous les jetons sont renvoyés du point d'extrémité du jeton [2].

Le Flux du code d'autorisation renvoie un code d'autorisation au client [3], qui peut alors l'échanger directement pour un jeton d'identification et un jeton d'accès. Cela offre l'avantage de ne pas exposer de jetons à l'agent utilisateur et éventuellement à d'autres applications malveillantes avec accès à l'agent utilisateur. Le serveur d'autorisation peut également authentifier le client avant d'échanger le code d'autorisation d'un jeton d'accès. Le flux du code d'autorisation est adapté aux applications clientes qui peuvent maintenir en toute sécurité un secret entre eux et le serveur d'autorisation.

3.1.1. Étapes du flux d'autorisation

Le Flux du code d'autorisation passe par les étapes suivantes :

Le client prépare une demande d'authentification contenant les paramètres de demande souhaités.
Le client envoie la demande au serveur d'autorisation.
Le serveur d'autorisation authentifie l'utilisateur final.
Le serveur d'autorisation obtient le consentement / l'autorisation de l'utilisateur final [4]
Le serveur d'autorisation renvoie l'utilisateur final au client avec un code d'autorisation.
Le client s'adresse au nœud final de jeton en utilisant le code d'autorisation afin d'obtenir les jetons.
Le client reçoit une réponse qui contient un jeton d'identification et un jeton d'accès dans le corps de réponse.
Le client valide le jeton d'ID et récupère l'identifiant du sujet de l'utilisateur final.

3.1.2. Point d'extrémité Autorization

Le point d'extrémité d'autorisation effectue l'authentification de l'utilisateur final. Pour ce faire, l'agent utilisateur doit être envoyé au point d'extrémité d'autorisation pour authentification et autorisation du serveur d'autorisations à l'aide des paramètres de requête définis par OAuth 2.0 et de paramètres et valeurs supplémentaires définis par OpenID Connect.

La communication avec le noeud final d'autorisation DOIT utiliser TLS. Voir Section 16.17 pour plus d'informations sur l'utilisation de TLS.

3.1.2.1. Paramètres d'autorisation

Les serveurs d'autorisation DOIVENT prendre en charge l'utilisation des méthodes HTTP GET et POST définies dans le RFC 2616 [RFC2616] au niveau du point d'extrémité d'autorisation. Les clients PEUVENT utiliser les méthodes HTTP GET ou POST pour envoyer la demande d'autorisation au serveur d'autorisation. Si vous utilisez la méthode HTTP GET, les paramètres de requête sont sérialisés à l'aide de la sérialisation de chaîne de requête URI, conformément à la Section 13.1. Si vous utilisez la méthode HTTP POST, les paramètres de demande sont sérialisés à l'aide de la sérialisation de formulaire, conformément à la Section 13.2.

OpenID Connect utilise les paramètres de requête OAuth 2.0 suivants avec le flux de codes d'autorisation :

scope
CHAMPS OBLIGATOIRES. Les demandes OpenID Connect DOIVENT contenir la valeur de la portée d'autorisation openid. Si la valeur openid n'est pas présente, le comportement est entièrement non spécifié. D'autres valeurs de domaine PEUVENT être présentes. Les valeurs de portée utilisées qui ne sont pas comprises par une implémentation DEVRAIENT être ignorées. Voir les sections 5.4 et 11 pour les valeurs de portée supplémentaires définies par cette spécification.

response_type
CHAMPS OBLIGATOIRES. OAuth 2.0 Response Type Valeur qui détermine le flux de traitement des autorisations à utiliser, y compris les paramètres renvoyés par les ordinateurs d'extrémité utilisés. Lorsque vous utilisez le flux de codes d'autorisation, cette valeur est "code".

client_id
CHAMPS OBLIGATOIRES. Identificateur de client OAuth 2.0 valide sur le serveur d'autorisations.

redirect_uri
CHAMPS OBLIGATOIRES. URI de redirection auquel la réponse sera envoyée. Cet URI DOIT correspondre exactement à l'une des valeurs d'URI de redirection pour le client préenregistré auprès du fournisseur OpenID, la correspondance étant effectuée comme décrit dans le paragraphe 6.2.1 de la [RFC3986] (comparaison de chaînes simples). Lors de l'utilisation de ce flux, l'URI de redirection DEVRAIT utiliser le schéma https; Cependant, il PEUT utiliser le schéma http, à condition que le type de client soit confidentiel, tel que défini dans la section 2.1 de OAuth 2.0, et que l'OP autorise l'utilisation des URI de redirection http dans ce cas. L'URI de redirection PEUT utiliser un autre schéma, tel qu'un schéma destiné à identifier un rappel dans une application native.

state
CONSEILLÉ [5]. Valeur opaque utilisée pour conserver l'état entre la demande et le rappel. En règle générale, l'atténuation de la falsification de requêtes intersites (CSRF, XSRF) s'effectue en liant de manière cryptographique la valeur de ce paramètre à un cookie de navigateur.

OpenID Connect utilise également le paramètre de requête OAuth 2.0 suivant, défini dans la section Pratiques de codage de types de réponses multiples de OAuth 2.0 [OAuth.Responses] :

response_mode
OPTIONNEL. Informe le serveur d'autorisations du mécanisme à utiliser pour renvoyer des paramètres à partir du point d'extrémité d'autorisation. Cette utilisation de ce paramètre n'est PAS RECOMMANDÉE lorsque le mode de réponse qui serait demandé est le mode par défaut spécifié pour le type de réponse.

Cette spécification définit également les paramètres de requête suivants :

nonce
OPTIONNEL. Valeur de chaîne utilisée pour associer une session client à un jeton d'ID et pour limiter les attaques de relecture. La valeur est transmise non modifiée de la demande d'authentification au jeton d'ID. Une entropie suffisante DOIT être présente dans les valeurs nonce utilisées pour empêcher les attaquants de deviner des valeurs. Pour les notes sur la mise en œuvre, voir la section 15.5.2.

display
OPTIONNEL. Valeur de chaîne ASCII indiquant comment le serveur d'autorisations affiche les pages d'interface utilisateur d'authentification et de consentement à l'utilisateur final. Les valeurs définies sont :

page
Le serveur d'autorisation DEVRAIT afficher l'interface utilisateur d'authentification et de consentement cohérente avec une vue complète de la page de l'agent d'utilisateur. Si le paramètre d'affichage n'est pas spécifié, il s'agit du mode d'affichage par défaut.
popup
Le serveur d'autorisation DEVRAIT afficher l'interface utilisateur d'authentification et de consentement cohérente avec une fenêtre d'agent d'utilisateur contextuelle. La fenêtre de l'agent d'utilisateur contextuelle doit être d'une taille appropriée pour une boîte de dialogue axée sur la connexion et ne doit pas masquer toute la fenêtre sur laquelle elle apparaît.
touch
Le serveur d'autorisation DEVRAIT afficher une interface utilisateur d'authentification et de consentement cohérente avec un dispositif utilisant une interface tactile.
wap
Le serveur d'autorisations DEVRAIT afficher l'interface utilisateur d'authentification et de consentement cohérente avec un affichage de type "smartphone".
Le serveur d'autorisations PEUT aussi tenter de détecter les capacités de l'agent d'utilisateur et présenter un affichage approprié.

prompt
OPTIONNEL. Liste de valeurs [6] de chaînes ASCII, séparées par des espaces et respectant la casse, spécifiant si le serveur d'autorisations invite l'utilisateur final à demander une nouvelle authentification et son consentement. Les valeurs définies sont :

none
Le serveur d'autorisations NE DOIT PAS afficher de pages d'interface utilisateur d'authentification ou de consentement. Une erreur est renvoyée si un utilisateur final n'est pas déjà authentifié ou si le client ne dispose pas du consentement préconfiguré pour les revendications demandées ou ne remplit pas les autres conditions de traitement de la demande. Le code d'erreur sera généralement login_required, interaction_required ou un autre code défini dans la section 3.1.2.6. Ceci peut être utilisé comme méthode pour vérifier l'authentification et / ou le consentement existants. [7]
login
Le serveur d'autorisation DEVRAIT demander à l'utilisateur final une nouvelle authentification. S'il ne peut pas réauthentifier l'utilisateur final, il DOIT retourner une erreur, généralement login_required.
consent
Le serveur d'autorisation DEVRAIT demander à l'utilisateur final son consentement avant de retourner les informations au client. S'il ne peut pas obtenir le consentement, il DOIT retourner une erreur, généralement consent_required.
select_account
Le serveur d'autorisation DEVRAIT demander à l'utilisateur final de sélectionner un compte d'utilisateur. Cela permet à un utilisateur final disposant de plusieurs comptes sur le serveur d'autorisations de choisir parmi plusieurs comptes pour lesquels il peut avoir des sessions en cours. S'il ne peut pas obtenir de choix de compte effectué par l'utilisateur final, il DOIT retourner une erreur, généralement account_selection_required.

max_age
OPTIONNEL. Âge d'authentification maximum. Spécifie le temps écoulé autorisé en secondes depuis la dernière fois que l'utilisateur final a été authentifié activement par l'OP. Si le temps écoulé est supérieur à cette valeur, l'OP DOIT tenter de ré-authentifier activement l'utilisateur final. (Le paramètre max_age request correspond au paramètre de requête OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age.) Lorsque max_age est utilisé, le jeton ID renvoyé DOIT inclure une valeur de déclaration auth_time.

ui_locales
OPTIONNEL. Langues et scripts préférés de l'utilisateur final pour l'interface utilisateur, représentés par une liste de valeurs d'étiquette de langue BCP47 [RFC5646] séparées par des espaces, triées par préférence. Par exemple, la valeur "fr-CA fr en" représente une préférence pour le français parlé au Canada, puis le français (sans désignation de région), suivi de l'anglais (sans désignation de région). Une erreur NE DEVRAIT PAS se produire si certains ou tous les paramètres régionaux demandés ne sont pas pris en charge par le fournisseur OpenID.

id_token_hint
OPTIONNEL. Le jeton ID précédemment émis par le serveur d'autorisations est transmis en tant qu'indicateur sur la session authentifiée actuelle ou passée de l'utilisateur final avec le client. Si l'utilisateur final identifié par le jeton ID est connecté ou est connecté par la requête, le serveur d'autorisations renvoie une réponse positive. sinon, il DEVRAIT retourner une erreur, telle que login_required. Si possible, un id_token_hint DEVRAIT être présent lorsque prompt = none est utilisé et une erreur invalid_request PEUT être renvoyée si ce n'est pas le cas ; Cependant, le serveur DEVRAIT répondre avec succès lorsque cela est possible, même s'il n'est pas présent. Authorization Server n'a pas besoin d'être répertorié en tant qu'audience du jeton ID lorsqu'il est utilisé en tant que valeur id_token_hint.
Si le jeton d'identification reçu par le RP en provenance de l'OP est chiffré, pour l'utiliser comme id_token_hint, le client DOIT déchiffrer le jeton d'identification signé contenu dans le jeton d'identification chiffré. Le client PEUT rechiffrer le jeton d'identification signé sur le serveur d'authentification à l'aide d'une clé permettant au serveur de déchiffrer le jeton d'ID et utiliser le jeton d'ID rechiffré en tant que valeur id_token_hint.

login_hint
OPTIONNEL. Indication au serveur d'autorisations sur l'identifiant de connexion que l'utilisateur final peut utiliser pour se connecter (si nécessaire). Cet indice peut être utilisé par un RP s'il demande d'abord à l'adresse électronique (ou à un autre identifiant) de messagerie électronique, puis de transmettre cette valeur au conseil en tant qu'indicateur. Il est RECOMMANDÉ que la valeur de conseil corresponde à la valeur utilisée pour la découverte. Cette valeur PEUT aussi être un numéro de téléphone dans le format spécifié pour la revendication n ° de téléphone. L'utilisation de ce paramètre est laissée à la discrétion du PO.

acr_values
OPTIONNEL. Valeur de "Requested Authentication Context Class Reference". Chaîne séparée par des espaces spécifiant les valeurs acr que le serveur d'autorisations est invité à utiliser pour traiter cette demande d'authentification, les valeurs apparaissant par ordre de préférence. La classe de contexte d'authentification satisfaite par l'authentification effectuée est renvoyée sous la valeur de revendication acr, comme spécifié à la section 2. La revendication acr est demandée en tant que revendication volontaire par ce paramètre.

D'autres paramètres PEUVENT être envoyés. Voir les sections 3.2.2, 3.3.2, 5.2, 5.5, 6 et 7.2.1 pour connaître les paramètres de demande d'autorisation et les valeurs de paramètre supplémentaires définis par cette spécification.

[1] Dès l'origine, le rapprochement des termes "authentification" et "autorisation" crée la confusion. Avez-vous lu : Généralités sur l'authentification, introduction d'OpenID Connect ?

[2] autrement dit, les jetons ne circulent que dans des relations serveur-serveur

[3] l'application cliente, à ne pas confondre avec le navigateur du client final ou "agent utilisateur".

[4] Toute la phraséologie d'OpenID Connect est déterminée par un cas d'utilisation particulier : celui où l'utilisateur final est propriétaire des données détenues par le serveur de ressource et auxquelles l'application souhaite accéder. Cependant, OpenID Connect peut également être utilisé pour authentifier l'utilisateur final et lui permettre d'accéder à des ressources qui ne lui appartiennent pas. Dans ce cas, la notion d'autorisation est inversée : c'est le propriétaire de l'application et des ressources protégées qui accorde l'accès.

[5] Obligatoire pour OAuthSD

[6] En réalité, toutes les combinaisons ne sont pas autorisées ou n'ont pas de sens. OAuthSD interprètera : 'none', 'login', 'login consent', 'consent'.

[7] La déclaration prompt='none' est utilisée notamment pour la procédure de ré-authentification silencieuse (Silent Re-authentication) et la surveillance de la validité de la session par iFrame. Voir : SSO et connexion unique (Single Login Identification, SLI), SSO et connexion unique (Single Login Identification, SLI) et Monitoring de l'état de l'authentification et SLO.

OpenID Connect OAuth Server dédié

Lien de (re)connexion

id_token_hint : ré-authentification silencieuse du sujet avec l'ID Token

Comment OAuthSD Implémente le traitement id_token_hint

Remarque de sécurité

OpenID Connect : Exemples complets du flux d'Autorisation via un code puis requête UserInfo

OpenID Connect : Obtenir les jetons d'accès

Point d'extrémité de jeton (Token Endpoint)

Forme de la demande de jeton d'accès

Réponse du serveur

Demande du jeton de rafraîchissement

Exemples de code

OpenID Connect : Obtenir une autorisation pour l'application cliente

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

Forme de la demande d'autorisation

Authentification de l'utilisateur final

Retour à l'application cliente

Situations d'erreur

Authentification utilisant le flux de code d'autorisation OpenID Connect

3.1. Authentification utilisant le flux de code d'autorisation OpenID Connect (Authorization Code Flow).

3.1.1. Étapes du flux d'autorisation

3.1.2.1. Paramètres d'autorisation