OpenID Connect OAuth Server dédié

Demande d'autorisation avec JWT (JWT Bearer Authorization Grant)

DnC — 2018-01-12T22:11:00Z

La particularité de ce flux est d'interroger le point d'accès token sans les identifiants (credentials) de l'application cliente, mais en passant un jeton JWT signé.

Spécification du flux JWT Bearer

(traduction d'extrait de la spécification draft-ietf-oauth-jwt-bearer-07 section 1)

2.1. Utilisation de JWT en tant qu'accord d'autorisation (Authorization Grants)

Pour utiliser un jeton JWT pour la demande d'autorisation, émettez une requête de jeton d'accès telle que définie dans la section 4 de la spécification 'Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [I-D.ietf-oauth-assertions]' avec les valeurs de paramètres et encodages spécifiques suivants.

La valeur du paramètre "grant_type" DOIT être "urn : ietf : params : oauth : grant-type : jwt-bearer".

La valeur du paramètre "assertion" DOIT contenir un seul JWT.

Le paramètre "scope" peut être utilisé pour indiquer la portée demandée.

L'authentification du client est facultative, comme décrit dans la Section 3.2.1 de OAuth 2.0 [RFC6749] et par conséquent, le "client_id" n'est nécessaire que lorsqu'un type d'authentification client qui repose sur ce paramètre est utilisé.

...

3.1. Traitement des accords d'autorisations

Les autorisations JWT peuvent être utilisées avec ou sans authentification ou identification du client. Que l'authentification du client soit requise ou non en conjonction avec un accord d'autorisation JWT, ainsi que les types d'authentification des clients pris en charge, sont des décisions de politique à la discrétion du serveur d'autorisation.
Cependant, si les informations d'identification du client sont présentes dans la demande, le serveur d'autorisation DOIT les valider.

Test du flux JWT Bearer avec OAuthSD

Il est possible de mettre ce flux en oeuvre avec OAuthSD. Le script ci-dessous donne un exemple d'appel au point de terminaison Token avec un jeton JWT fabriqué localement.

PHP

/* test_JWTBearer.php
Usage : https://oa.dnc.global/oidc/tests/test_JWTBearer.php
Author :
Bertrand Degoy https://degoy.com
Credits :
bschaffer https://github.com/bshaffer/oauth2-server-php
Licence : MIT licence
*/
ini_set('display_errors', 1);
// Autoloading by Composer
require __DIR__ . '/../../vendor/autoload.php';
OAuth2\Autoloader::register();
//***** Configuration *****
$client_id = 'testopenid'; // iss
$user_id = 'bebert'; // subject
$server = 'oa.dnc.global';
$token_endpoint = 'https://' . $server . '/token';
define('PRIVATE', true);
require_once __DIR__.'/../../oidc/includes/configure.php';
require_once __DIR__.'/../../oidc/includes/utils.php';
//*** End of configuration ***
// Connect to database
$cnx = new \PDO($connection['dsn'], $connection['username'], $connection['password']);
// Get private key
$stmt = $cnx->prepare($sql = "SELECT * FROM spip_public_keys WHERE client_id=:client_id");
$stmt->execute(compact('client_id'));
$keyinfo = $stmt->fetch(\PDO::FETCH_ASSOC);
if ( empty($keyinfo) ) {
$response->setError(401, 'invalid_token', "Invalid aud"); //DEBUG only
$response->send();
die;
}
$private_key = $keyinfo['private_key'];
$grant_type = 'urn:ietf:params:oauth:grant-type:jwt-bearer';
$jwt = generateJWT($private_key, $client_id, $user_id, 'https://' . $server);
passthru("curl " . $token_endpoint . " -d 'grant_type=$grant_type&assertion=$jwt'");
/**
* Generate a JWT
*
* @param $privateKey The private key to use to sign the token
* @param $iss The issuer, usually the client_id
* @param $sub The subject, usually a user_id
* @param $aud The audience, usually the URI for the oauth server
* @param $exp The expiration date. If the current time is greater than the exp, the JWT is invalid
* @param $nbf The "not before" time. If the current time is less than the nbf, the JWT is invalid
* @param $jti The "jwt token identifier", or nonce for this JWT
*
* @return string
*/
function generateJWT($privateKey, $iss, $sub, $aud, $exp = null, $nbf = null, $jti = null)
{
if (!$exp) {
$exp = time() + 1000;
}
$params = array(
'iss' => $iss,
'sub' => $sub,
'aud' => $aud,
'exp' => $exp,
'iat' => time(),
);
if ($nbf) {
$params['nbf'] = $nbf;
}
if ($jti) {
$params['jti'] = $jti;
}
$jwtUtil = new OAuth2\Encryption\Jwt();
return $jwtUtil->encode($params, $privateKey, 'RS256');
}

Télécharger

En cas de succès, le serveur retourne quelque chose comme :

{"access_token":"8d2bea8d956f74030d8837deacd6154dbc0df262","expires_in":3600,"token_type":"Bearer","scope":"basic"}

à vérifier

Commentaire sur la sécurité du flux JWT Bearer

L'application cliente doit posséder un jeton JWT valide. Si elle l'a obtenu par OpenID Connect, elle ne peut l'avoir fait qu'en envoyant les identifiants d'application au point d'accès Token (dont le secret de l'application), et c'est précisément ce que le flux permet d'éviter. La solution : l'application cliente doit posséder la clé privée (ou y accéder) afin de générer le jeton JWT à son niveau. Cela nous place dans le cas très particulier des "applications de confiance". Nous savons que ce type d'applications doit se trouver dans un espace de communication protégé par TLS.

Ce flux peut être utilisé pour permettre à une application cliente d'accéder à une ressource protégée sans autorisation de l'utilisateur final (on considère que les données protégées sont la propriété de l'application). Dans cette configuration, nous sommes dans un flux comparable à l'Autorisation de Serveur à serveur (Client Credentials Grant), avec une sécurité supplémentaire : le jeton JWT signé apporte une certitude sur l'identité de l'application cliente.

Une fonction pour tout simplifier !

DnC — 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

/**
* Interface avec OAuthSD, Autorisation via un code (Authorization Code Grant).
* Cette fonction interroge une API protégée et retourne le résultat au format JSON.
* Si l'API refuse l'accès, une demande d'authentification de l'utilisateur final est lancée automatiquement.
*
* @param mixed $request : URI de l'appel à l'API REST
* @return mixed string, bool : Résultat de la requête au format JSON ou false en cas de refus d'accès.
*/
function ProtectedApi_GET_auto ( $request ) {
include_spip('inc/headers');
include_spip('inc/distant');
$token = $_SESSION['oauth_access_token'];
if ( !$token ) {
if ( isset($_GET['token']) ) {
$token = $_GET['token'];
}
}
if ( !empty($token) ) {
// Interroger la ressource protégée
$request_response = recuperer_url($request . "&token=$token");
if ( (int)$request_response['status'] == 200 ) {
// Ok
return $request_response['page'];
} elseif ( (int)$request_response['status'] == 401 ) {
// Pas le droit d'accéder à cette ressource.
// Commencer par vérifier le jeton
$url = "http://oa.dnc.global/oauth/resource.php?access_token=" . $token;
$resource_response = recuperer_url($url);
$status = (int)$resource_response['status'];
$page = json_decode($resource_response['page'], true);
$error = $page['error'];
$error_description = $page['error_description'];
switch( $status ) {
case 200 :
// Le jeton était valide,ne pas boucler!
return false;
break;
case 401 :
if ( $error == 'expired_token' ) {
// Rafraîchir le jeton expiré
// Interroger Token
$options = array(
'methode' => '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);
}

Télécharger

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

Télécharger

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

Validation du jeton par une ressource protégée

DnC — 2017-03-24T17:21:00Z

Un serveur de ressource protégé (RS) et, plus généralement, une application tierce, sont distincts de l'application cliente et du serveur d'autorisation (AS).

Il s'agit de définir comment un RS valide le jeton d'accès qui accompagne une requête de la part de l'application cliente.

Position du problème

Nous sommes ici au cœur du problème !

La norme OAuth 2.0 n'indique pas comment les serveurs de ressources (RS) qui reçoivent un jeton d'accès doivent procéder pour le valider.

La spécification OAuth 2.0, RFC6749, aborde cette question dans la section 7 :

"Les méthodes utilisées par le serveur de ressource pour valider le jeton d'accès (ainsi que toute réponse d'erreur) dépassent le cadre de cette spécification, mais impliquent généralement une interaction ou une coordination entre le serveur de ressources et le serveur d'autorisation".

Justin Richer traite magistralement ce sujet dans cet article : In OAuth 2.0, how do resource servers assert a token issued by an authorization server ? et se trouve à l'origine de ce document : RFC 7662 : OAuth 2.0 Token Introspection.

Eran Hammer, qui a activement contribué à l'élaboration de la norme, expose ce qui suit : OAuth v2 communication between authentication and resource server.

Deux cas se présentent :

1. Le serveur de ressource (RS) et le serveur d'autorisation (AS) sont colocalisés, ou communiquent par un canal sûr, comme un tunnel SSH. Dans tous les cas, ils appartiennent tous deux à une même organisation.

Le RS peut donc accéder aux informations nécessaires (comme la clé publique d'une paire publique/privée) pour décoder la signature.

La plupart des articles traitant de ce sujet s'appuient sur ce cas de figure pour sauter à pieds joints sur la technique de validation de la signature. Nous estimons que ce cas est trivial : si le RS communique de façon sûre avec l'AS, alors il n'est nullement besoin d'un serveur d'authentification.

2. Le serveur de ressource (RS) n'est pas directement lié au serveur d'autorisation (AS).

Dans ce cas, il existe deux familles de méthodes :
la première consiste à authentifier le jeton d'accès par interrogation du serveur d'autorisation (introspection).
la deuxième consiste à ce que l'application tierce assure localement l'authentification du jeton d'accès.

Ceci est développé dans ce qui suit :

Authentification du jeton d'accès par interrogation du serveur d'autorisation (introspection)

Cette méthode présente un avantage important : elle permet de savoir si le jeton a été révoqué avant la fin de sa période de validité.

Elle a cependant l'inconvénient d'augmenter le trafic avec le SA, ce qui peut être minimisé par une mise en cache des réponses du côté du RS.

OAuth Server by DnC offre des Points d'extrémité d'introspection pour OAuthSD et OpenID Connect auxquels les applications tierces peuvent s'adresser pour effectuer la validation du jeton d'accès.

Identity Server 3 et Word Perfect offrent également un point d'extrémité pour la validation du jeton d'accès.

Authentification du jeton d'accès par le serveur de ressource (RS)

Une approche un peu rapide d'OAuth peut laisser croire qu'il existe une magie permettant de valider localement un jeton d'accès sans que RS et AS ne soient aucunement liés. En fait, il faudra toujours une forme de secret partagé entre le RS et l'AS.

A ce point, il existe (encore) deux voies distinctes ( la très mauvaise et la bonne ) :

le cryptage symétrique du jeton (parfois appelé "jeton auto-décryptable"), qui n'est qu'une forme d'obfuscation si l'on considère la faible durée de vie d'un cryptage symétrique et la difficulté de partager la clé sans la compromettre.
Nous traiterons rapidement de l'obfuscation. Cette voie peut parfois s'avérer utile pour protéger des données peu sensibles contre les curieux et les robots.
Ainsi que le dit Fabio Galloneto dans l'article intitulé "Securing Sensitive Strings" : "Pour résoudre le problème, la première stratégie qui vient à l'esprit est l'obfuscation. ... la "sécurité par l'obscurité" n'est pas la sécurité. Cela vaut la peine de souligner que par définition un système sécurisé est « un système conçu de sorte que si quelqu'un sait tout sur le fonctionnement du système, il est toujours sécurisé » (voir le principe de Kerckhoff) et que l'obfuscation n'ajoute rien à la sécurité dans ce contexte."

la validation à l'aide de cryptage asymétrique (signature).

C'est encore Eran Hammer qui démontre la nécessité de signer les jetons pour authentifier : OAuth 2.0 (sans signature) est mauvais pour le Web :

"OAuth 2.0 supprime les signatures et la cryptographie en faveur des jetons portés, semblables aux cookies. En tant qu'éditeur d'OAuth 2.0, je suis associé au protocole OAuth 2.0 plus que la plupart des autres, et l'hypothèse est que je suis d'accord avec les décisions et les orientations prises par le protocole. Bien que le fait d'être éditeur donne un certain degré de contrôle temporaire sur la spécification, les décisions sont finalement prises par le groupe dans son ensemble (comme il se doit).
Et dans son ensemble, la communauté OAuth a commis une grave erreur (ndlr : en supprimant la signature des jetons) quant à l'orientation future du protocole. Une erreur qui fera d'OAuth 2.0 un agent de changement beaucoup moins important [1] sur le Web."

La recherche de la sécurité nous amène donc à faire valider le jeton (localement ou par introspection) par l'application tierce. C'est ce que permet la signature du jeton JWT (JSON Web Token).
Plusieurs implémentations utilisent un tel jeton :

OpenID Connect

Le protocole OpenID Connect utilise un jeton d'identité (ID Token) fondé sur JWT, signé cryptographiquement (JWS). La norme décrit comment une application cliente doit valider un ID Token reçu en réponse à une demande d'authentification. Un tiers (le serveur de ressource protégé notamment) peut évidemment appliquer la même méthode, à condition d'accéder aux informations nécessaires. La validation est effectuée notamment à l'aide d'une signature faisant appel à un cryptage asymétrique, mettant en œuvre une paire de clé publique-privée, ce qui suppose que l'application cliente accède à la clé publique.

OAuthSD offre toutes les réponses à ces questions :
Validation du jeton d'identité ID Token (JWT signé ou JWS),
OpenID Connect : Exemples complets du flux d'Autorisation via un code puis requête UserInfo,
API OpenID Connect : Découverte.
Vérifier le jeton est une chose. Il est tout aussi important de vérifier que l'application qui le présente le détient légitimement (il peut s'agir d'un jeton volé), voyez :
Vérification de l'origine de la requête reçue par un serveur de ressource.

Différentes plateformes mettent en œuvre la validation du jeton d'identité :

Identity Server

IdentityServer3 : AccessTokenValidation

Google Identity Plateform

Google Identity Plateform

Exchange 2013

Exchange 2013 utilise aussi un jeton JWT pour le jeton d'identité, qui est similaire à l'ID Token défini par OpenID Connect. Il est donc intéressant de consulter les documents suivants :

Présentation du jeton d'identité Exchange

Utilisation de PHP pour valider un jeton d'identité

[1] Un euphémisme pour dire "un changement catastrophique pour la sécurité du Web".

OAuth 2.0 : Obtenir une autorisation pour l'application cliente

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

Télécharger

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.

OAuth 2.0 : Autorisation de serveur à serveur, exemple complet

DnC — 2016-12-03T15:21:32Z

Le flux Autorisation de Serveur à serveur (Client Credentials Grant) du protocole OAuth 2.0 permet à une application cliente d'obtenir un jeton d'accès au vu de ses identifiants.

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

Nous indiquons également comment les choses se passent du côté du serveur de ressource.

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 Serveur à serveur.
Cliquez sur l'image pour l'agrandir

Ce flux n'identifie pas l'utilisateur final, qui n'entre pas en ligne de compte. Il est donc utile pour effectuer des tâches requérant un accès de l'application à des ressources protégées hors du contrôle de l'utilisateur final.

Du côté du client

Voici un exemple en PHP pour SPIP 3.1 :

SPIP

/**
* Interface avec OAuthSD, Flux d'autorisation de serveur à serveur
* (Client Credentials Grant).
* Cette fonction interroge une API protégée et retourne le résultat au format JSON.
* Si l'API refuse l'accès, une nouvelle demande de jeton est lancée automatiquement.
*
* @param mixed $request : URI de l'appel à l'API REST
* @return mixed string, bool : Résultat de la requête au format JSON ou false en
* cas de refus d'accès.
*
* Auteur: B.Degoy DnC https://degoy.com/#dnc_conteneur_contact
* licence GNU/GPL v3
*
*/
function ProtectedApi_GET_auto( $request ) {
$session_name = session_name();
if ( empty($session_name) ) {
session_name('PHPSESSID');
}
session_start();
include_spip('inc/headers');
include_spip('inc/distant');
if ( isset($_GET['token']) ) $token = $_GET['token'];
if ( !$token ) $token = $_SESSION['oauth_access_token'];
if ( !empty($token) ) {
// Interroger la ressource protégée
$request_response = recuperer_url($request . "&token=$token");
if ( (int)$request_response['status'] == 200 ) {
// Ok
return $request_response['page'];
} elseif ( (int)$request_response['status'] == 401
OR (int)$request_response['status'] == 403 ) {
// Pas le droit d'accéder à cette ressource.
// Commencer par vérifier le jeton
$url = "http://oa.dnc.global/oauth/resource.php?access_token=" . $token;
$resource_response = recuperer_url($url);
$status = (int)$resource_response['status'];
$page = json_decode($resource_response['page'], true);
$error = $page['error'];
$error_description = $page['error_description'];
switch( $status ) {
case 200 :
// Si le jeton était valide, ne pas boucler!
return false;
break;
default :
// Demander un nouveau jeton et recommencer
unset($_SESSION['oauth_access_token']);
return _replay( $request );
break;
}
return false;
}
} else {
// Demander un nouveau jeton et recommencer
return _replay( $request );
}
}
function _replay( $request ) {
if ( $token = GetToken() ) {
$_SESSION['oauth_access_token'] = $token;
$_GET['token'] = $token;
ProtectedApi_GET_auto( $request );
} else return false;
}
/**
* Demander un nouveau jeton d'accès au serveur OAuth
* Flux Client Credentials Grant
*
* Auteur: B.Degoy DnC https://degoy.com/#dnc_conteneur_contact
* licence GNU/GPL v3
*
*/
function GetToken() {
// Interroger Token
$jeton = '';
$url = 'http://oa.dnc.global/token.php';
$options = array(
'method' => 'POST',
'datas' => array(
'grant_type' => 'client_credentials',
'client_id' => 'radar',
'client_secret' => '01fc4587ab1c23ff456e448dab18327a',
)
);
$res = recuperer_url( $url, $options );
$page = json_decode($res['page'], true);
$token = $page['access_token'];
return ( (!empty($token))? $token : false );
}

Télécharger

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 :

PHP

// Le nom de l'application cliente
define ( 'APPNAME', 'radar' );
// La requete
$req = "http://chemindeleau.com/?page=gis.json&pt=1";
echo '
Résultat de : ' . $req . '

';
$api_result = ProtectedApi_GET_auto( $req );
if ( $api_result == false ) {
$api_result = "Erreur !";
} else {
echo
'
```
';
```
print_r( json_decode( $api_result, true ));
echo '';
}

Télécharger

Du côté du serveur de ressource

Voici un exemple de serveur de ressource simple :

SPIP

#CACHE{2}
[(#REM)
Liste de Tagazd en JSON.
Nécessite les plugins geobase et gis.
Exemple d'appel:
http://xxx.com/?page=gis.json&pt=nn
où nn est l'id du point dans la table gis.
Copyright (c) 2001-2016
Arnaud Martin, Antoine Pitrou, Philippe Riviere, Emmanuel Saint-James
Copyright(c) 2013-2016 DnC
Auteur: B.Degoy DnC https://degoy.com/#dnc_conteneur_contact
Licence GNU/GPL v3
]
function oauth_authorize($accesstoken) {
if ( !empty( $accesstoken ) ) {
// Interroger OAuth Server by DnC
include_spip('inc/distant');
// Vérifier le jeton d'accès (access token)
$url = "https://oa.dnc.global/oauth/resource.php?access_token=" . $accesstoken;
$res = recuperer_url($url);
if ( (int)$res['status'] === 200 ) {
return true ;
}
}
return false;
}
if ( !(bool)@oauth_authorize(_request('token')) ) {
header("HTTP/1.0 401 Unauthorized");
die();
}
// Si le jeton est valide, demander à SPIP d'émettre le contenu au format JSON :
?>
#HTTP_HEADER{Content-Type: application/json; charset=#CHARSET}
[
[(#ARRAY{
id,#ID_GIS,
titre,#TITRE,
distance,[(#DISTANCE|format_kmm)],
quadrant,[(#ENV{pt,1}|quadrant{#ID_GIS})],
lat,#LAT,
lon,#LON,
url,#URL_SITE_SPIP/?page=photo&id_document=#ID_DOCUMENT,
}|json_encode)]
]

Télécharger

La première partie du code en PHP valide le jeton d'accès auprès du serveur OAuthSD. En cas d'échec, l'exécution est interrompue et le serveur retourne le code HTTP 401 (Non autorisé) et un contenu vide.

Dans la deuxième partie "écrite en SPIP", vous remarquerez comme SPIP permet de générer facilement toute sortes de contenus à partir de données diverses. Nous avons ici une jointure entre des documents et des points géographiques retournée au format application/json.

Lancer un test

Ce test met en œuvre le code présenté ci-dessus.
Les rôles sont les suivants :
application cliente et utilisateur final : radar (r.dnc.global),
serveur de ressource (données protégées) (API Rest) : chemindeleau.com,
serveur d'authentification : oa.dnc.global,

Lancer le test get-gis-data_exemple

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

L'application cliente demande au serveur les points situés à moins de 100km autour du point pt=1, qui correspond à la "Fontaine chaude" de Bourbonnes-les-bains. Le résultat est ordonné par distance croissante.

Vous obtiendrez la réponse suivante :

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

DnC — 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

/*
Autorisation avec OAuth Server by DnC
Retour de OAuth authorize.
Ce fichier doit être installé du côté de l'application cliente.
Il correspond au Point d'extrémité de redirection, ou URI de
retour à l'application cliente (Redirection Endpoint).
Auteur : Bertrand degoy
Copyright (c) 2016 DnC
*/
//*
$session_name = session_name();
if ( empty($session_name) ) {
session_name('PHPSESSID');
}
if ( isset($_GET['state']) ) session_id($_GET['state']);
session_start();
//*/
// Code d'autorisation (Authorization code) retourné par le serveur
$authcode = $_GET['code'];
$sanitized_authcode = preg_replace('/[^a-f0-9"\']/', '', $authcode);
if ( $sanitized_authcode === $authcode ) {
// Demander un jeton d'accès pour l'application
$jeton = '';
$url = 'http://oa.dnc.global/oauth/token.php';
$datas = array(
'grant_type' => '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
}
?>

Télécharger

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.

OAuth 2.0 : Les Types d'Autorisation (Grant Type)

DnC — 2016-11-03T06:29:43Z

Dans le cadre du protocole OAuth 2.0, OAuth Server by DnC traite les types d'autorisation suivants :
Autorisation via un code (Authorization Code Grant),
Autorisation Implicite (Implicit Grant)
Autorisation via mot de passe (User Credentials, Resource Owner Password Credentials Grant),
Autorisation serveur à serveur (Client Credentials Grant),
JWT Bearer (JWT Bearer Authorization Grant) .

Voyez également : OpenID Connect et OAuth 2.0 : Synthèse des flux d'autorisation (Grant Type).

Ce qui suit (une bonne partie, hormis les notes) est une traduction du document RFC 6749 [1].

Autorisation via un code (Authorization Code Grant)

Le code d'autorisation est obtenu en utilisant un serveur d'autorisation comme intermédiaire entre le client [2] et le propriétaire de la ressource [3]. Au lieu de demander l'autorisation directement au propriétaire de la ressource, le client dirige le propriétaire de la ressource vers un serveur d'autorisation (via son user-agent [4] tel que défini dans [RFC2616]), qui à son tour ramène le propriétaire de la ressource au client avec le code d'autorisation.
Avant de rediriger le propriétaire de la ressource vers le client avec le code d'autorisation, le serveur d'autorisation authentifie le propriétaire de la ressource [5], et obtient l'autorisation. Étant donné que le propriétaire de la ressource s'authentifie uniquement auprès du serveur d'autorisation, les références du propriétaire de la ressource ne sont jamais partagées avec le client.
Le code d'autorisation présente quelques avantages de sécurité importants, tels que la capacité d'authentifier le client [6], ainsi que la transmission du jeton d'accès directement au client [7] sans passer par l'user-agent du propriétaire de la ressource et potentiellement l'exposer à d'autres, y compris le propriétaire de la ressource [8].

Avertissement : pour des développements nouveaux, il sera souvent préférable d'utiliser OpenID Connect : Autorisation via un code (Authorization Code Flow). Un avantage important d'OIDC est la transmission aux applications et aux ressources protégées du jeton JWT liant l'identité de l'utilisateur final, celle de l'application et une définition de la portée des autorisations accordées.

Autorisation via mot de passe (User Credentials, Resource Owner Password Credentials Grant)

L'accréditation via mot de passe [9] du propriétaire de ressource (c'est-à-dire nom d'utilisateur et mot de passe) peut être utilisée directement comme demande d'autorisation pour obtenir un jeton d'accès. L'accréditation ne doit être utilisée que lorsqu'il existe un degré de confiance élevé entre le propriétaire de la ressource et le client (par exemple le client fait partie du système d'exploitation de l'appareil ou d'une application ayant des privilèges élevés), et lorsque d'autres types de soumission d'autorisation ne sont pas disponibles (tel qu'un code d'autorisation).

Même si ce type de soumission nécessite un accès direct du client aux informations d'identification du propriétaire de la ressource [10], les informations d'identification du propriétaire de la ressource sont utilisées pour une demande unique et sont échangés contre un jeton d'accès. Ce type de soumission peut éliminer la nécessité pour le client de stocker les informations d'identification du propriétaire de la ressource pour un usage futur, grâce à un jeton d'accès à vie longue ou un jeton de rafraîchissement.

Autorisation serveur à serveur (Client Credentials Grant)

Les informations d'identification du client (ou d'autres formes d'authentification client) peuvent être utilisées comme une soumission d'autorisation lorsque le périmètre d'autorisation est limité aux ressources protégées sous le contrôle du client, ou à des ressources protégées précédemment négociées avec le serveur d'autorisation. Typiquement, les informations d'identification client sont utilisées comme une autorisation lorsque le client agit en son propre nom (le client est propriétaire de la ressource) ou demande l'accès à des ressources sur la base d'une autorisation préalablement négociée par le serveur d'autorisation [11].

Fin de la traduction du document RFC 6749.

Derrière les affirmations sur la sécurité, il apparait clairement que ces flux ne sont sécurisés que si l'on peut "faire confiance" aux applications clientes. Autant dire qu'ils ne sont sécurisés que dans un espace propriétaire (corporate realm). Il manque une signature pour authentifier le client, comme le démontre brillament Eran Hammer, un des concepteurs d'OAuth 2.0 : OAuth 2.0 (sans signature) est mauvais pour le Web.

Sur le sujet, voyez également : Typologie des applications au regard de la sécurité des données.

JWT Bearer (JWT Bearer Authorization Grant)

Ce flux d'autorisation présente la particularité de fournir un jeton JWT (JSON Web Token) au point d'accès Token pour obtenir un jeton d'accès.

Ce flux est également désigné par "Client Authentication" dans la RFC 7523.

Notes :
OAuthSD propose une approche unifiée des flux et des points d'entrée des protocoles OAuth 2.0 et d'OpenID Connect :
OpenID Connect et OAuth 2.0 : Synthèse des flux d'autorisation (Grant Type),
OpenID Connect et OAuth 2.0 : Les points d'extrémité d'OAuthSD
Certains auteurs définissent dans le cadre d'OAuth 2.0 un flux "Refresh Token Grant" s'adressant au point d'extrémité de jeton. Il ne s'agit pas à proprement parler d'un flux puisque, prolongeant un flux d'autorisation établi précédemment, il ne peut exister de façon autonome. Voir : Rafraîchir (actualiser) un jeton d'accès.

[1] Ceci est une première approche, car cette norme comporte de nombreuses ambiguïtés, voire des erreurs conceptuelles, qui obscurcissent la compréhension de OAuth.

[2] Dans le vocabulaire d'OAuth, le terme "client" désigne une application cliente, c'est à dire l'application demandant l'accès à la ressource protégée.

[3] En réalité, le serveur d'autorisation n'a pas la moindre idée du propriétaire de la ressource. Tout ce qu'il voit, c'est un utilisateur quelconque qui utilise une certaine application, laquelle délègue au serveur d'autorisation l'identification de l'utilisateur. Que celui-ci soit effectivement le propriétaire de la ressource préjuge de la suite du processus dite "authentification", qui implique le serveur de ressource, car seul celui-ci a une idée de qui sont les propriétaires des données. On préfèrera le terme "utilisateur final" (end user) pour désigner l'internaute qui tente d'accéder aux données protégées à travers l'application cliente.

[4] Dans le cas général l'"user-agent" est le navigateur de l'utilisateur.

[5] C'est précisément ce que ne fait pas le protocole OAuth qui n'est pas un protocole d'authentification. OAuth doit être encapsulé dans une couche de protocole supplémentaire tel que OpenID Connect pour assurer cette fonction. Voyez : Généralités sur l'authentification, introduction d'OpenID Connect.

[6] Sous certaines conditions, notamment s'il s'agit d'une application Web. Voir : Typologie des applications au regard de la sécurité des données.

[7] à l'application cliente

[8] Cette dernière phrase est assez incompréhensible. Il est bien évident que ce n'est pas le propriétaire de la ressource qui présente un risque de sécurité, mais un internaute quelconque, éventuellement malveillant, ou son navigateur éventuellement pollué par un malware. Il y a constamment confusion entre user-agent (le navigateur de n'importe quel internaute) et le propriétaire de la ressource. Il faut comprendre : "y compris n'importe quel user-agent mis en œuvre par un Internaute mal intentionné ou pollué par un malware."

[9] Pourquoi parler de mot de passe, cela est très restrictif. Le serveur d'autorisation peut présenter à l'utilisateur différents moyens de s'identifier, par exemple un lecteur de carte, la reconnaissance biométrique etc..

[10] Pas seulement : les informations d'identification doivent également circuler entre l'application et le serveur d'autorisation, ce qui retire presque tout intérêt à ce mode d'autorisation.

[11] La deuxième phrase de cette définition est une paraphrase de la première, et semble plutôt meilleure.

OAuth 2.0 : Points d'extrémité

DnC — 2016-10-23T17:18:59Z

Note : Les points d'extrémité du protocole OpenID Connect sont traités ici : API OpenID Connect : Points d'extrémité.

Points d'extrémité définis par OAuth 2.0

Le point d'extrémité d'autorisation et le point d'extrémité de jeton sont tous deux situés sur le serveur d'autorisation (ce serveur). OAuth Server by DnC y ajoute trois points d'extrémé.

Le point d'extrémité de redirection est situé dans l'application cliente.

Les points d'extrémité sont illustrés dans ce schéma (cas du flux d'Autorisation via un code) :

OAuth 2.0 Endpoints.

La spécification OAuth 2.0 ne décrit pas comment l'URI de ces points d'extrémité est définie ni les documente. C'est à chaque développeur de décider. Voici comment OAuth Server by DnC définit les points d'extrémité :

Point d'extrémité d'autorisation (Authorization Endpoint)
https://oa.dnc.global/oauth/authorize.php
Usage : OAuth 2.0 : Obtenir une autorisation pour l'application cliente.

Le point d'extrémité d'autorisation est le point d'extrémité sur le serveur d'autorisation auquel l'utilisateur final se connecte à l'aide de l'user-agent (en général un navigateur Web), et accorde l'autorisation à l'application cliente.

Point d'extrémité de redirection, ou URI de retour à l'application cliente (Redirection Endpoint)
Le point d'extrémité de redirection est le point d'extrémité dans l'application cliente vers lequel le user-agent est redirigé, après avoir obtenu l'autorisation au point d'extrémité d'autorisation. 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.

Point d'extrémité de jeton (Token Endpoint)
https://oa.dnc.global/oauth/token.php
Usages : OAuth 2.0 : Obtenir un jeton d'accès, Rafraîchir (actualiser) un jeton d'accès.

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, l'ID client et le secret, pour obtenir un jeton d'accès ou rafraîchir un jeton d'accès ayant expiré.

Points d'extrémité définis par OAuth Server by DnC pour la vérification du jeton d'accès

Point d'extrémité de ressource (Resource Endpoint) [1]
https://oa.dnc.global/oauth/resource.php
Usage : Validation du jeton d'accès par interrogation du point d'extrémité "resource"

Dans l'exemple de flux ci-dessus, l'envoi à l'application cliente d'un jeton d'accès valide lui permet d'être "logged-in". La plupart des sites web et blogs décrivant OAuth ne traitent pas de la validation du jeton d'accès. Ceci veut-il dire que leur approche du protocole se limite à l'authentification des utilisateurs pour l'accès à l'application ?

Cependant, ce n'est pas fini : l'intérêt d'un jeton d'accès réside dans l'usage qui en sera fait par l'application cliente pour signaler à un serveur de ressources protégées qu'elle est autorisée à obtenir des données.

La norme OAuth 2.0 n'indique pas comment les serveurs de données protégées qui reçoivent un jeton d'accès doivent procéder pour le valider, que ce soit localement ou en s'adressant à point d'entrée dédié à sa validation. Cette problématique est exposée ici dans sa généralité : Validation du jeton par une ressource protégée.

OAuth 2.0 Server PHP offre un contrôleur pour la vérification de la validité du jeton d'accès.

Avec OAuth Server by DnC, les serveurs de ressource (Resource API) peuvent accéder au point d'extrémité "resource" pour valider le jeton d'accès reçu et obtenir des informations complémentaires.

OAuth Server by DnC offre également le point d'extrémité suivant :

Point d'extrémité d'introspection (Introspection Endpoint)
https://oa.dnc.global/oauth/introspect.php
Le document RFC 7662 : OAuth 2.0 Token Introspection propose une méthode identique dans le principe et très proche dans la réalisation. Les données retournées sont au format JSON et se rapprochent du contenu d'un JSON Web Token (JWT). OAuthSD adapte également cette spécification à l'introspection (vérification) de l'ID Token fourni par OpenID Connect.

Point d'extrémité de révocation (Revocation Endpoint)

OAuth Server by DnC expose le point de terminaison 'revoke' pour la révocation d'un jeton :
https://oa.dnc.global/oauth/revoke.php
Usage : Révoquer un jeton.

[1] Aussi connu sous le nom de Resource Owner Endpoint

OAuth 2.0 : Lier une application cliente au serveur OAuthSD

DnC — 2016-10-08T08:29:47Z

Cet article s'adresse à un développeur.

Il décrit comment adapter une application pour qu'elle devienne cliente OAuth 2.0 et comment l'inscrire sur OAuth Server byDnC.

Ceci suppose que le développeur ou son organisation soit inscrit sur le serveur en tant qu'Administrateur d'applications.

Le processus comporte deux aspects :

du côté du serveur OAuth, inscrire l'application,
du côté de l'application cliente, insérer le code nécessaire pour assurer le lien avec le serveur OAuth.

1. S'inscrire en tant qu'Administrateur d'applications

L'inscription se fait ici : Formulaire d'inscription.

Renseignez soigneusement votre fiche d'Administrateur d'application, la plupart de ces informations étant communiquées aux utilisateurs finaux dont vous devez gagner la confiance.

Attention : ne confondez pas l'inscription en tant qu'Administrateur d'applications (un développeur qui inscrit son application cliente pour qu'elle puisse déléguer l'authentification à OAuthSD) avec l'inscription d'un internaute en tant qu'utilisateur final des applications clientes, qui se fait ici : Je m'inscris.

Notes :
Le terme "Administrateur d'applications" permet de distinguer le développeur ou le propriétaire d'une application cliente qui s'inscrit sur ce serveur, de l'utilisateur final, qui doit aussi s'inscrire, mais autrement. Dans le modèle de données sous-jacent, il s'agit également de l'objet éditorial de SPIP (la table Auteurs), tandis que l'utilisateur final correspond à une table distincte.

2. Inscrire l'application cliente sur le serveur OAuthSD

Dans la rubrique Gérer, aller à Ajouter (Inscrire) une application cliente et remplir le formulaire :

Client Id (obligatoire) : Chaine identifiant l'application de façon unique. Entrez un nom court, sans espace ni caractère spécial autre que '_'. Cet identifiant doit être unique pour tous les administrateurs d'applications inscrits sur le serveur. Il est visible du public et doit donc être représentatif de l'application et de votre entreprise.

Client secret (obligatoire) : une courte chaîne assimilable à un mot de passe fort. Ce code n'apparait que dans ce dialogue et doit rester secret.

Redirect uri (obligatoire) : URI de retour à l'application cliente. C'est l'adresse à laquelle le serveur OAuth fait retour sur le client avec le résultat de l'authentification.

Grant Type (obligatoire) : sélectionnez un des Types d'autorisation.

Scopes (obligatoire) : Liste des Scopes autorisés pour l'application, séparés par un espace. Dans une phase de test ou pour une application simple, si vous n'avez pas défini de scope, indiquez "basic".

User id ID de l'utilisateur unique de l'application. Utilisé notamment pour l'autorisation serveur à serveur. Laissez vide si votre application ne nécessite pas de définition de l'UserId.

Vérifiez vos entrées et actionnez le bouton "Enregistrer".

Vous pourrez retrouver l'application et la modifier à la rubrique Toutes vos applications clientes.

Enfin, naviguez à l'adresse https://oa.dnc.global/keys afin de créer l'entrée correspondant à la nouvelle paire de clés publique/privée.

Vous pourrez retrouver l'application et la modifier à la rubrique Toutes vos applications clientes.

Notes :
OAuthSD crée pour l'application cliente une paire de clés publique/privée. Si vous souhaitez la changer, allez à la rubrique Toutes vos applications clientes et sélectionnez l'action "clés" correspondant à l'application.
OAuth Server by DnC étant conforme à la spécification OAuth 2.0, toute application apte à déléguer ses autorisations à un serveur compatible OAuth 2.0 peut être inscrite sans modification sur OAuth 2 Server by DnC.

3. Insérer dans l'application le code nécessaire

Si l'application cliente est conçue pour déléguer ses authentifications à un serveur à la norme OAuth 2.0, il n'y a rien de plus à faire.

Sinon, c'est une affaire de développeur. Il y a deux adaptations à réaliser :

Écrire le code situé au Point d'extrémité de redirection, ou URI de retour à l'application cliente (Redirection Endpoint). Il s'agit de demander au serveur OAuth un jeton d'accès pour l'application, à partir du Code d'autorisation (Authorization code) retourné par le serveur. Nous en donnons un exemple ici : Exemple de code pour le Point d'extrémité de redirection.

Consommer une API protégée de type HTTP REST est extrêmement simple. Voici un exemple avec L'API REST de Radar : Une fonction pour tout simplifier !.

Notes :
OAuth Server by DnC étant conforme à la spécification OAuth 2.0, l'adaptation de l'application décrite ci-dessus lui permettra de déléguer ses autorisations à n'importe quel serveur compatible OAuth 2.0.

OpenID Connect OAuth Server dédié

Demande d'autorisation avec JWT (JWT Bearer Authorization Grant)

Spécification du flux JWT Bearer

Test du flux JWT Bearer avec OAuthSD

Commentaire sur la sécurité du flux JWT Bearer

Une fonction pour tout simplifier !

Lancer un test

Validation du jeton par une ressource protégée

Position du problème

Authentification du jeton d'accès par interrogation du serveur d'autorisation (introspection)

Authentification du jeton d'accès par le serveur de ressource (RS)

OAuth 2.0 : Obtenir une autorisation pour l'application cliente

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

Forme de la demande d'autorisation

Retour à l'application cliente

OAuth 2.0 : Autorisation de serveur à serveur, exemple complet

Du côté du client

Résultat de : ' . $req . '

Du côté du serveur de ressource

Lancer un test

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

OAuth 2.0 : Les Types d'Autorisation (Grant Type)

Autorisation via un code (Authorization Code Grant)

Autorisation via mot de passe (User Credentials, Resource Owner Password Credentials Grant)

Autorisation serveur à serveur (Client Credentials Grant)

JWT Bearer (JWT Bearer Authorization Grant)

OAuth 2.0 : Points d'extrémité

Points d'extrémité définis par OAuth 2.0

Points d'extrémité définis par OAuth Server by DnC pour la vérification du jeton d'accès

Point d'extrémité de révocation (Revocation Endpoint)

OAuth 2.0 : Lier une application cliente au serveur OAuthSD

1. S'inscrire en tant qu'Administrateur d'applications

2. Inscrire l'application cliente sur le serveur OAuthSD

3. Insérer dans l'application le code nécessaire