Documents de référence

, par DnC

Documents essentiels

Synthèse : OAuth 2.0
Code : Brent Shaffer’s OAuth Server PHP

Documents de l’IETF

-  RFC 6749 L’architecture d’authentification OAuth 2.0.
L’architecture d’autorisation OAuth 2.0 permet à une application tierce d’obtenir un accès limité à un service HTTP, soit au nom d’un propriétaire de ressource en orchestrant une interaction d’approbation entre le propriétaire de la ressource et le service HTTP, soit en autorisant l’application tierce à obtenir l’accès en son propre nom.

- RFC 7523 JSON Web Token (JWT) Profil pour les soumissions d’authentification et d’autorisation de client OAuth 2.0.
Cette spécification définit l’utilisation d’un JSON Web Token (JWT) Bearer Token comme moyen de demander un jeton d’accès OAuth 2.0 ainsi que pour l’authentification du client.

- RFC 7516 JSON Web Encryption (JWE)
JSON Web Encryption (JWE) représente du contenu chiffré basé sur JSON. Les algorithmes cryptographiques et les identificateurs à utiliser avec cette spécification sont décrits dans le document JSON Spécification des Algorithmes Web (JWA) et registres IANA définis par cette spécification. En relation, la signature numérique et les capacités du Code d’Authentification de Message (MAC) sont décrites dans le document séparé Spécification JSON Web Signature (JWS).

- RFC 7515 JSON Web Signature (JWS)
JSON Web Signature (JWS) représente du contenu sécurisé par signature numérique ou des codes d’authentification de message (MACs) utilisant des structures de données basées sur JSON. Les algorithmes cryptographiques et les identificateurs à utiliser avec cette spécification sont décrits dans le document JSON Web Algorithmes (JWA) et un registre IANA défini par la spécification. Les capacités de cryptage associées sont décrites par la spécification distincte JSON Web Encryption (JWE).

- RFC 7662 OAuth 2.0 Token Introspection
Cette spécification définit une méthode permettant à une ressource protégée d’interroger un serveur d’autorisation OAuth 2.0 pour déterminer l’état actif d’un jeton OAuth 2.0 et pour déterminer des méta-informations sur ce jeton.
Les déploiements OAuth 2.0 peuvent utiliser cette méthode pour transmettre à la ressource protégée des informations sur le contexte d’autorisation du jeton à partir du serveur d’autorisation.

-  RFC 7009 OAuth 2.0 Token Revocation.
Ce document propose un point d’extrémité supplémentaire pour le serveur d’autorisation OAuth, qui permet aux clients d’avertir le serveur d’autorisation qu’un jeton de rafraîchissement ou d’accès précédemment obtenu n’est plus nécessaire. Cela permet au serveur d’autorisation de nettoyer les données de sécurité. Une demande de révocation invalidera le jeton en question et, le cas échéant, d’autres jetons basés sur la même autorisation.

OpenID Connect

La référence : OpenID Connect.

OpenID Connect Core 1.0 incorporating errata set 1
OpenID Connect 1.0 est une couche d’identité simple fondée sur le protocole OAuth 2.0. Il permet aux clients de vérifier l’identité de l’utilisateur final en fonction de l’authentification effectuée par un serveur d’autorisation, ainsi que d’obtenir des informations de profil de base sur l’utilisateur final de manière interopérable et REST.
Cette spécification définit la fonctionnalité de base OpenID Connect : authentification construite sur OAuth 2.0 et l’utilisation de revendications pour communiquer des informations sur l’utilisateur final. Il décrit également les considérations de sécurité et de confidentialité pour l’utilisation d’OpenID Connect.

OpenID Connect Basic Client Implementer’s Guide 1.0 - draft 37
OpenID Connect 1.0 est une couche d’identité simple fondée sur le protocole OAuth 2.0. Il permet aux clients de vérifier l’identité de l’utilisateur final en fonction de l’authentification effectuée par un serveur d’autorisation, ainsi que d’obtenir des informations de profil de base sur l’utilisateur final de manière interopérable et REST.
Ce Guide d’implémentation OpenID Connect Basic Client 1.0 contient un sous-ensemble de la spécification OpenID Connect Core 1.0 conçue pour être facile à lire et à implémenter pour les échanges entre applications Web basés sur le flux d’autorisation OAuth. Ce document double intentionnellement le contenu de la spécification Core pour fournir un guide d’implémentation autonome pour des développements d’applications Web élémentaires utilisant le flux de code d’autorisation OAuth.
Les fournisseurs OpenID et les applications non Web doivent plutôt consulter la spécification Core.

Documents de Microsoft Exchange

Exchange 2013 utilise un jeton JWT (JSON Web Token) pour le jeton d’identité. La documentation technique d’Exchange appelle "Jeton d’identité" quelque chose de très 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é

Envoi d’une requête à une ressource protégée

, par DnC

Dans cet article, nous traitons de l’accès à une ressource protégée de type HTTP REST, avec les bonnes pratiques.

Envoi d’une requête à une ressource protégée

Il y a trois méthodes pour l’envoi d’une requête à une ressource protégée : une bonne, une acceptable et une non recommandée :

Ce qui suit est pour l’essentiel une traduction de parties de la RFC 6750, section 2

2. Requêtes authentifiées

Cette section définit trois méthodes d’envoi de jetons d’accès aux serveurs de ressources. Les clients NE DOIVENT PAS utiliser plus d’une méthode pour transmettre le jeton dans chaque requête.

2.1. Demande d’autorisation par Champ d’en-tête (la bonne méthode)

Lors de l’envoi du jeton d’accès par l’en-tête de la requête (Request Header) dans le champ "Authorization" défini par HTTP / 1.1 [RFC2617], le client utilise le schéma d’authentification "Bearer" pour transmettre le jeton d’accès.
Par exemple :

    GET / resource HTTP / 1.1
    Host: oa.dnc.global
    Authorization: Bearer mF_9.B5f-4.1JqM

Exemples :

PHP

  1. $h = curl_init('https://oa.dnc.global/userinfo');
  2. curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
  3. curl_setopt($h, CURLOPT_TIMEOUT, 10);
  4. curl_setopt($h, CURLOPT_HTTPHEADER,
  5. array('Authorization: Bearer '
  6. . $access_token));
  7. $res = curl_exec($h);

Télécharger

SPIP

  1. $url = "https://oa.dnc.global/userinfo";
  2. $options = array(
  3. 'methode' => 'GET',
  4. 'datas' => 'Authorization: Bearer ' . $access_token,
  5. );
  6. $res = recuperer_url($url, $options);

Télécharger

Les clients DOIVENT faire des requêtes authentifiées avec un jeton Bearer en utilisant le champ d’en-tête de demande « Authorization » avec le schéma d’autorisation du protocole HTTP « Bearer ». Les serveurs de ressources DOIVENT supporter cette méthode.

2.2. Paramètres form-urlencoded dans le corps (une méthode acceptable)

Lors de l’envoi du jeton d’accès dans le corps d’entité de requête HTTP, le Client ajoute le jeton d’accès au corps de requête en Paramètre "access_token". Le client NE DOIT PAS utiliser cette méthode à moins que toutes les conditions suivantes sont remplies :
- L’entête d’entité de requête HTTP inclut le champ d’en-tête "Content-Type" "application / x-www-form-urlencoded".
- Le corps de l’entité suit les exigences d’encodage du type de contenu "Application / x-www-form-urlencoded" tel que défini par HTML 4.01 [W3C.REC-html401-19991224].
- Le corps de l’entité de demande HTTP est mono-partie.
- Le contenu codé dans le corps de l’entité DOIT se composer entièrement de d caractères ASCII [USASCII].
- La méthode de requête HTTP suit la sémantique définie pour le corps de requête. En particulier, cela signifie que la méthode "GET" NE DOIT PAS être utilisée.

Le corps de l’entité PEUT inclure d’autres paramètres spécifiques aux requêtes, auquel cas le paramètre "access_token" DOIT être correctement séparé des paramètres spécifiques à la requête en utilisant le caractère "&" (ASCII Code 38).

Par exemple, le client effectue la requête HTTP suivante en utilisant la sécurité des couches de transport :

    POST / ressource HTTP / 1.1
    Host: oa.dnc.global
    Content-Type: application/ x-www-form-urlencoded
    access_token = mF_9.B5f-4.1JqM

La méthode "application/ x-www-form-urlencoded" NE DOIT PAS être utilisée sauf dans les contextes d’application où les navigateurs participants n’ont pas accès au champ d’en-tête de demande "Authorization". Les serveurs PEUVENT soutenir cette méthode.

Exemple :
PHP

  1. $data2 = array(
  2. 'access_token' => $access_token,
  3. );
  4. $h = curl_init($userinfo_endpoint);
  5. curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
  6. curl_setopt($h, CURLOPT_TIMEOUT, 10);
  7. curl_setopt($h, CURLOPT_POST, true);
  8. curl_setopt($h, CURLOPT_HTTPHEADER,
  9. array('Content-Type: application/x-www-form-urlencoded'));
  10. curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data2));
  11. $res = curl_exec($h);

Télécharger

2.3. Paramètres de requête dans l’URI (la mauvaise méthode)

Lors de l’envoi du jeton d’accès dans l’URI de requête HTTP, le client ajoute le jeton d’accès au composant de requête de l’URI tel que défini par "Uniform Resource Identifier (URI) : Syntaxe générique" [RFC3986], en utilisant le paramètre "access_token".

Par exemple, le client effectue la requête HTTP suivante en utilisant la sécurité des couches de transport :

    GET /resource?access_token=mF_9.B5f-4.1JqM HTTP / 1.1
    Host: oa.dnc.global

...

Les clients utilisant la méthode URI Query Parameter DEVRAIENT également envoyer un entête Cache-Control contenant l’option "no-store". Les réponses de succès (status 2XX) du serveur à ces demandes Serveur DOIVENT contenir un entête Cache-Control avec l’option "private".

En raison des faiblesses de sécurité associées à la méthode URI (Voir la section 5), y compris la forte probabilité que l’URL contenant le jeton d’accès soit enregistrée, elle NE DOIT PAS être utilisée à moins qu’il soit impossible de transporter le jeton d’accès dans le champ d’en-tête de requête "Authorization" ou dans le corps d’entité de la requête HTTP. Les serveurs de ressources PEUVENT supporter cette méthode.

Cette méthode est incluse pour documenter une utilisation possible ; son utilisation n’est pas recommandée en raison de ses déficiences en matière de sécurité (voir section 5), mais également parce qu’elle utilise un nom de paramètre de requête réservé, ce qui est contraire aux meilleures pratiques de l’espace de noms URI, définies par « Architecture of the World Wide Web, Volume One" [W3C.REC-webarch-20041215]

Voir aussi :
- Validation du jeton d’accès par interrogation du serveur d’autorisation (Introspection)
- Contrôle d’accès HTTP (CORS)

Portée de l’autorisation (Scope)

, par DnC

Les Scopes définissent l’étendue des droits (les actions permises sur les données de la ressource protégée) attachés au jeton d’accès qui est transmis par l’application cliente aux applications tierces (Serveurs de ressources). Celles-ci énumèrent les scopes attachés à l’autorisation ; elles ont la responsabilité d’agir en conséquence pour permettre ou non l’accès de l’application cliente aux données protégées.

Il est important de noter que les droits portés par un scope ne dépendent que de la façon dont l’application tierce en tient compte (ou non). Autrement dit, l’application tierce doit être une application de confiance, parfaitement identifiable par l’utilisateur final. De même, l’utilisateur final doit être authentifié. OAuth Server by DnC s’attache à apporter des solutions innovantes pour la qualification des applications et des utilisateurs, ce qui constitue une grande part de sa valeur ajoutée.

Définition

L’attribut "scope" est défini dans la section 3.3 de la [RFC6749].

L’attribut "scope" est une liste de valeurs de portée sensibles à la casse, délimitées par des espaces, indiquant la portée requise du jeton d’accès pour accéder à la ressource demandée.

Les valeurs "scope" sont définies par l’implémentation ; il n’y a pas de registre centralisé pour eux ; les valeurs autorisées sont définies par le serveur d’autorisation.

L’ordre des valeurs "scope" n’est pas significatif.

Dans certains cas, la valeur "scope" sera utilisée lors de la demande d’un nouveau jeton d’accès avec une étendue d’accès suffisante pour utiliser la ressource protégée.

L’utilisation de l’attribut "scope" est OPTIONNELLE.

L’attribut "scope" NE DOIT PAS apparaître plus d’une fois.

Deux cas de figure

La norme OAuth 2.0 (RFC 6749) distingue deux cas de figure dans lesquels les scopes seront utilisés différemment :

1. L’utilisateur final est propriétaire des données protégées, et c’est donc lui qui autorise l’accès à ses données par les applications clientes tierces. Pour cela il sélectionne les scopes parmi ceux qui lui sont présentés au moment de la procédure d’autorisation. Le serveur de ressource ne doit permettre l’accès qu’aux ressources autorisées en fonction des scopes sélectionnés. [1].

2. L’application cliente est elle-même propriétaire des données situées sur les serveurs de ressources : elle autorise l’utilisateur final à accéder à ces données en son nom propre. Dans ce cas, les scopes sont définis par l’application cliente [2]. Il est important de considérer que cela donne à l’application cliente le moyen de moduler les autorisations selon le statut ou le profil de l’utilisateur, ce qui est un mécanisme très puissant puisque cette modulation de l’autorisation est propagée aux applications tierces.

Voyez également Identity by DnC qui apporte une solution innovante pour moduler les scopes selon le profil des utilisateurs.

La norme OAuth 2.0 ne donne pas un jeu de scopes prédéfini

OAuth définit les scopes et les mécanismes attachés de façon très générale. Rappelons que OAuth sert de base à différents protocoles qui en font un usage différent selon les applications.

Un jeu de scopes peut être défini à la fois pour segmenter un ensemble de données en sous-ensembles (diviser un profil en identité, adresse postale, données personnelle etc.), ou pour définir les actions (lecture, écriture, suppression etc.) permises sur les données, ou ces deux usages simultanément.
On voit qu’ils dépendent de la nature des ressources et de l’utilisation que pourraient en faire les applications clientes. Les scopes peuvent donc être très variés.

Un serveur OAuth suivant la norme OAuth 2.0 (comme c’est le cas de OAuth Server by DnC) doit donc être totalement transparent à leur définition et à leur usage :
- les scopes sont définis par le concepteur du serveur de ressources,
- c’est au serveur de ressource d’assurer le respect des autorisations définies par les scopes accompagnant le jeton d’accès au moment de la requête,
- les scopes qu’une application cliente peut utiliser sont librement définis au moment de son inscription sur le serveur d’autorisation.

Ceci a des conséquences très importantes :

- Soit les scopes ont une définition très générale, et le serveur de ressource peut répondre à des requêtes en provenance d’application clientes qui lui sont totalement étrangères,

- Soit les scopes ont une signification plus précise, et les serveurs de ressources comme les applications clientes doivent avoir une connaissance mutuelle. Cela peut se produire dans le cadre d’un protocole particulier, dans un ensemble particulier d’applications ou dans un espace contrôlé par une organisation (corporate realm).

OpenID Connect : une définition partielle des scopes

OpenID Connect est un protocole d’authentification construit sur OAuth.

Concernant les scopes, OpenID connect définit un jeu de scopes standards, adaptés à la fonction d’authentification de l’utilisateur final, mais permet également l’utilisation de scopes particuliers.

Notes

[1C’est souvent beaucoup plus simple que cela : l’application signale les scopes qu’elle demande, et l’utilisateur final termine la procédure si les données réclamées (claims) lui conviennent, ou abandonne

[2Ou plus généralement "par l’implémentation". En effet, le concepteur de l’application cliente définit les scopes en fonction de ce qu’elle attend et de ce qu’elle en fait. Mais les scopes autorisés pour une application cliente peuvent être utilisés ou non, assortis éventuellement d’un paramètre, en fonction des droits que l’on veut accorder à l’utilisateur final. Ceci peut aussi bien être déterminé par le serveur d’authentification au moment où l’on crée le jeton, en fonction de conditions extérieures à l’application cliente.

Gestion et définition des Scopes dans OAuthSD

, par DnC

La portée de l’autorisation est définie par les Scopes. C’est un sujet que doit maîtriser le développeur d’une application utilisant OpenID Connect.

Trois niveaux de définition des scopes

1. Les Scopes réservés (Reserved Scopes) :

Les Scopes réservés jouent un rôle particulier. Ils sont essentiellement utilisés par le serveur pour modifier le comportement des flux. Ils peuvent être interprétés par une application pour un usage particulier.

- openid : ce scope est obligatoire pour que l’application puisse fonctionner avec OpenID Connect.

- offline_access :

- sli : ce scope est obligatoire pour que l’application accepte l’identification unique (Single Login Identification, SLI) et la ré-authentification silencieuse (Silent Re-Authentication, SRA).

Ces Scopes doivent apparaître dans les Scopes autorisés ET dans les Scopes demandés.

2. Les Scopes autorisés pour une application (available scopes)

Ces scopes sont définis au moment de l’enregistrement d’une application sur le serveur.

En plus des scopes réservés, cette liste comprend des scopes non-réservés (Non Reserved Scopes), soit définis par OpenID, soit définis à l’initiative du concepteur de l’application.

à développer : Default Scope.

3. Les Scopes demandés par une application (required scopes)

Une application demande les Scopes dans la requête d’authentification.
Ces scopes doivent être autorisés pour l’application.

Réaliser l’identification (Authentification)

, par DnC

Rappelons le : OAuth n’est pas un protocole d’authentification. Cela provient du fait qu’une application cliente qui reçoit un code d’autorisation (Authorization Code) de la part de OAuth n’a aucune connaissance de l’identité de l’utilisateur qui a émis l’autorisation, et ne peut donc savoir si il est le propriétaire de données protégées. Ces informations ne sont pas véhiculées par le code d’autorisation. C’est la même chose pour un serveur de ressource qui reçoit un jeton d’accès (Access Token).

Par définition, l’authentification suppose d’accéder aux données d’identification. De plus, seul le serveur de ressources sait à qui appartiennent les ressources (typiquement un jeu de données associées à une personne). L’authentification ne peut donc être réalisée qu’avec une étape supplémentaire mettant en jeu le serveur de ressources.

Notons que OAuth Server by DnC prend quelques libertés en étendant la norme avec un point d’extrémité "resource" qui permet de valider les jetons d’accès et d’obtenir l’identificateur de l’utilisateur final ainsi que des données sur son profil. Voir : Validation du jeton d’accès par interrogation du serveur d’autorisation (Introspection).

Différentes solutions permettent de construire une authentification avec OAuth. Elles consistent à accéder à une API ( un web service ) associé au serveur OAuth pour obtenir les informations sur l’utilisateur.

Malheureusement, il y a autant d’API que de fournisseur d’authentification (Providers) : Google, Facebook, Twitter, LinkedIn etc.). Ces fournisseurs désignent leur protocole d’authentification sous le nom de OAuth, alors qu’il s’agit de protocoles particuliers construits au-dessus ou à côté de OAuth. Cette confusion, et la distinction qu’il convient de faire, sont expliquées en détail dans cet article : Généralités sur l’authentification, introduction d’OpenID Connect.

Face à ce problème, il existe (au moins) deux solutions :
- utiliser une bibliothèque permettant d’abstraire le processus d’accès aux données, pré-configurée pour les fournisseurs les plus connus ;
- utiliser le protocole OpenID Connect qui, largement utilisé, peut faire figure de standard.

Cette deuxième solution nous parait préférable, dans la mesure où la plupart des fournisseurs d’authentification (et en particulier Google) proposent maintenant OPenID Connect.

Utiliser OpenID Connect

Nous décrivons dans cet article comment mettre en oeuvre OpenID Connect dans une application cliente :
- OpenID Connect : Lier une application cliente au serveur OAuthSD

Les articles suivants décrivent plus en détail l’implémentation de OpenID Connect par OAuth Server byDnC :
- OpenID Connect
- Réponse UserInfo

Utiliser une couche d’abstraction

Dans cet article, nous décrivons comment intégrer PHPoAuthUserData avec Lusitanian/PHPoAuthLib : (à développer).
Finlement, nous nous ramenons au protocole OpenID Connect. L’intérêt de cette approche et de permettre d’adapter une application utilisant OAuth avec Lusitanian/PHPoAuthLib au standard OpenID Connect. Nous donnerons PhpBB comme exemple (à développer).

Contrôle d’accès HTTP (CORS)

, par DnC

Les requêtes HTTP de type multi-origines (Cross-Origin Request) sont des requêtes pour des ressources localisées sur un domaine différent de celui qui est à l’origine de la requête.

C’est exactement la configuration dans laquelle nous nous trouvons quand nous voulons appliquer les protocoles d’authentification à la communication entre applications réparties sur Internet.

Du fait de nombreux abus (attaques de type cross-site request forgery ou CSRF), les requêtes HTTP croisées ont été sujettes à des restrictions pour des raisons de sécurité bien compréhensibles.

Le but de cet article et d’expliquer comment franchir ces restrictions en toute légitimité et sécurité dans le cadre de la mise en oeuvre du service OAuth Server by DnC.

Références :
- Contrôle d’accès HTTP
- Cross-Origin Resource Sharing
- Les attaques de type cross-site request forgery

Différents cas de figure

Comme toujours lorsque nous abordons la question de la communication entre applications réparties sur différents domaines, nous devons d’abord distinguer deux cas :
- les serveurs de ressources protégées (RS) sont interrogés par des applications clientes identifiées à l’avance ; c’est toujours le cas lorsque les applications et les RS appartiennent à une même organisation ;
- les RS n’ont pas une connaissance préalable des applications.

Le premier cas est trivial. L’autorisation des requêtes multi-origines (Cross-Origin Request) [1] pourra être donnée, par exemple, dans le fichier .htaccess du RS :

##### CORS pour monsite.com :
SetEnvIf Origin "^http(s)?://(.+\.)?monsite\.com$" origin_is=$0
Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is

Seul le deuxième cas mérite notre attention.

Autorisation après validation du jeton d’accès

Dans le deuxième cas (l’application cliente n’est pas connue du RS) notre solution consiste à inscrire le champ Access-Control-Allow-Origin dans la réponse du serveur de ressource (RS) si, et seulement si, le jeton a été validé auprès du serveur d’autorisation. Cela semble la bonne méthode, puisque le RS s’en remet au serveur d’autorisation pour réaliser toutes les vérifications nécessaires, et n’a donc pas besoin de connaître le domaine d’origine de la requête [2].

Voici un exemple de fonction d’autorisation en PHP pour SPIP 3.1, dans laquelle le RS valide le jeton par introspection (voir : Validation du jeton d’accès par interrogation du serveur d’autorisation (Introspection)) :

  1. /*
  2. Autorisation avec OAuth Server by DnC
  3. Auteur : Bertrand degoy
  4. Copyright (c) 2016 DnC
  5. */
  6.  
  7. function oauth_authorize($accesstoken) {
  8.  
  9. if ( !empty( $accesstoken ) ) {
  10.  
  11. // Interroger OAuth Server by DnC
  12. include_spip('inc/distant');
  13. // Vérifier le jeton d'accès (access token)
  14. $url = "http://oa.dnc.global/oauth/resource.php?access_token=" . $accesstoken;
  15. $res = recuperer_url($url);
  16. if ( (int)$res['status'] === 200 ) {
  17. if ( isset($_SERVER["HTTP_ORIGIN"]) ) {
  18. // Accès HTTP (CORS) : autoriser l'origine
  19. $issuer = trim(strtr($_SERVER["HTTP_ORIGIN"], '<>"\'', '[]##'));
  20. header('Access-Control-Allow-Origin', $issuer);
  21. }
  22. return true ;
  23. }
  24.  
  25. } else return false;
  26.  
  27. }

Télécharger

Tester : http://chemindeleau.com/?page=test-rpc-3 (utilise la fonction ProtectedApi_GET_auto() décrite ici : Une fonction pour tout simplifier !).

Cet exemple s’appuie sur l’API HTTP REST de Radar. Le site Chemin de l’eau est un site opérationnel qui met en œuvre des fonctionnalités issues des prototypes OAuthSD et Radar.

Message d’erreur : Blocage d’une requête multi-origines

"Blocage d’une requête multi-origines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur http://r.dnc.global/http.api/collectionjson/gis?lat=47.8655638&lon=5.3314162&dmax=10&token=. Raison : échec du canal de pré-vérification des requêtes CORS."

La requête suivante, bien que le type indiqué soit ’GET’, est négociée avec la méthode ’OPTIONS’. Il en résulte que la requête cross-site est de type requête prévérifiée ("preflighted requests") :

  1. <div id="result"></div>
  2.  
  3. <script>
  4.  
  5. $.ajax({
  6.  
  7. url: 'http://r.dnc.global/http.api/collectionjson/gis',
  8. dataType: 'json',
  9. type: 'GET',
  10. contentType: 'application/json',
  11. data: 'lat=47.8655638&lon=5.3314162&dmax=10&token=#SESSION{auth_token}',
  12. timeout: 15000,
  13. success: function(data) {
  14. var text = '<b>Requete : ' + data.collection.href + '</b><br /><br />';
  15. items = data.collection.items;
  16. for (var i=0; i < items.length; i++ ) {
  17. for (var j=0; j < items[i].data.length; j++ ) {
  18. text += items[i].data[j].name + '=' + items[i].data[j].value + "<br />";
  19. }
  20. text += "<br />";
  21. }
  22. $("#result").html(text);
  23.  
  24. },
  25. error: function(oops) {
  26. // oops.statusText returns error
  27. $("#result").html(oops.statusText);
  28.  
  29. }
  30. });
  31.  
  32. </script>

Télécharger

Cliquez sur la vignette pour voir la requête et la réponse :

PNG - 41.6 ko

(Article à compléter. Mais est-ce pertinent ? L’utilisation de script expose le jeton, ce n’est pas la méthode recommandée).

Notes

[1La traduction française "multi-origines" est inexacte : la requête n’a évidemment qu’une seule origine, mais celle-ci est indéfinie vue du RS, et en tous cas issue d’un domaine différent du sien.

[2Voici une démonstration claire de la différence entre autorisation et authentification : le serveur de ressource va répondre sans rien savoir de l’identité de l’application cliente ni de l’utilisateur final. OpenID Connect permet de réaliser l’authentification, donc de répondre (ou non) en fonction de l’identité de l’application, de l’utilisateur final, voire des portées d’autorisation (scopes)

FAQ pour le développeur (administrateur d’application)

, par DnC

Les développeurs s’inscrivent sur OAuth Server by DnC en tant qu’administrateurs d’applications. Il sont notamment propriétaires d’une ou plusieurs applications clientes qu’il ont configurées sur le serveur à l’aide de ce site web.