Aller au contenu principal

3. Obtaining Authorization Server Metadata (Obtention des métadonnées du serveur d'autorisation)

Les serveurs d'autorisation qui prennent en charge les métadonnées doivent (MUST) rendre un document JSON contenant les métadonnées spécifiées dans la section 2 disponible à un chemin formé en insérant une chaîne d'URI bien connue (well-known) entre le composant hôte et le composant chemin (s'il existe) de l'identifiant d'émetteur du serveur d'autorisation. Par défaut, la chaîne d'URI bien connue utilisée est /.well-known/oauth-authorization-server. Ce chemin doit (MUST) utiliser le schéma "https". La syntaxe et la sémantique de ".well-known" sont définies dans RFC 5785 [RFC5785]. Le suffixe d'URI bien connu utilisé doit (MUST) être enregistré dans le registre IANA "Well-Known URIs" [IANA.well-known].

Différentes applications utilisant un serveur d'autorisation OAuth de manière spécifique à l'application peuvent (MAY) définir et enregistrer différents suffixes d'URI bien connus utilisés pour publier les métadonnées du serveur d'autorisation utilisées par ces applications. Par exemple, si une application exemple utilise un serveur d'autorisation OAuth de manière spécifique à l'exemple et doit publier des valeurs de métadonnées spécifiques à l'exemple, elle pourrait enregistrer et utiliser le suffixe d'URI "example-configuration" et publier le document de métadonnées en insérant /.well-known/example-configuration entre les composants hôte et chemin de l'identifiant d'émetteur du serveur d'autorisation. Alternativement, de nombreuses applications de ce type utiliseront la chaîne d'URI bien connue par défaut /.well-known/oauth-authorization-server, qui est le choix approprié pour les serveurs d'autorisation OAuth génériques, et n'enregistreront pas de chaîne spécifique à l'application.

Les applications OAuth 2.0 utilisant cette spécification doivent (MUST) spécifier quel suffixe d'URI bien connu elles utiliseront à cette fin. Le même serveur d'autorisation peut (MAY) choisir de publier ses métadonnées à plusieurs emplacements bien connus dérivés de son identifiant d'émetteur, par exemple, en les publiant à la fois à /.well-known/example-configuration et à /.well-known/oauth-authorization-server.

Certaines applications OAuth choisiront d'utiliser le suffixe d'URI bien connu "openid-configuration". Comme indiqué dans la section 5, bien que l'identifiant /.well-known/openid-configuration semble spécifique à OpenID, son utilisation dans cette spécification se réfère en fait à une fonctionnalité OAuth 2.0 générale et n'est pas spécifique à OpenID Connect.

3.1. Authorization Server Metadata Request (Requête de métadonnées du serveur d'autorisation)​

Le document de métadonnées du serveur d'autorisation doit (MUST) être interrogé en utilisant une requête HTTP "GET" au chemin précédemment spécifié.

Lorsque l'identifiant d'émetteur est https://example.com et que le suffixe d'URI bien connu est "oauth-authorization-server", le client fera la requête suivante pour obtenir les métadonnées, car l'identifiant d'émetteur ne contient pas de composant chemin :

GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com

Si la valeur de l'identifiant d'émetteur contient un composant chemin, tout "/" final doit (MUST) être supprimé avant d'insérer /.well-known/ et le suffixe d'URI bien connu entre les composants hôte et chemin. Lorsque l'identifiant d'émetteur est https://example.com/issuer1 et que le suffixe d'URI bien connu est "oauth-authorization-server", le client fera la requête suivante pour obtenir les métadonnées, car l'identifiant d'émetteur contient un composant chemin :

GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com

L'utilisation de composants de chemin permet de prendre en charge plusieurs émetteurs par hôte. Cela est nécessaire dans certaines configurations d'hébergement multi-tenant. Cette utilisation de ".well-known" est destinée à prendre en charge plusieurs émetteurs par hôte ; contrairement à son utilisation dans RFC 5785 [RFC5785], elle ne fournit pas d'informations générales sur l'hôte.

3.2. Authorization Server Metadata Response (Réponse de métadonnées du serveur d'autorisation)​

La réponse est un ensemble de revendications sur la configuration du serveur d'autorisation, y compris tous les points de terminaison nécessaires et les informations sur l'emplacement des clés publiques. Une réponse réussie doit (MUST) utiliser le code d'état HTTP 200 OK et retourner un objet JSON utilisant le type de contenu "application/json" qui contient un ensemble de revendications comme ses membres qui sont un sous-ensemble des valeurs de métadonnées définies dans la section 2. D'autres revendications peuvent (MAY) également être retournées.

Les revendications retournant plusieurs valeurs sont représentées sous forme de tableaux JSON. Les revendications avec zéro élément doivent (MUST) être omises de la réponse.

Les réponses d'erreur utilisent les valeurs de code d'état HTTP applicables.

Voici un exemple de réponse non normatif :

HTTP/1.1 200 OK
Content-Type: application/json

{
 "issuer":
   "https://server.example.com",
 "authorization_endpoint":
   "https://server.example.com/authorize",
 "token_endpoint":
   "https://server.example.com/token",
 "token_endpoint_auth_methods_supported":
   ["client_secret_basic", "private_key_jwt"],
 "token_endpoint_auth_signing_alg_values_supported":
   ["RS256", "ES256"],
 "userinfo_endpoint":
   "https://server.example.com/userinfo",
 "jwks_uri":
   "https://server.example.com/jwks.json",
 "registration_endpoint":
   "https://server.example.com/register",
 "scopes_supported":
   ["openid", "profile", "email", "address",
    "phone", "offline_access"],
 "response_types_supported":
   ["code", "code token"],
 "service_documentation":
   "http://server.example.com/service_documentation.html",
 "ui_locales_supported":
   ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}

3.3. Authorization Server Metadata Validation (Validation des métadonnées du serveur d'autorisation)​

La valeur "issuer" retournée doit (MUST) être exactement identique à la valeur de l'identifiant d'émetteur du serveur d'autorisation dans laquelle la chaîne d'URI bien connue a été insérée pour créer l'URL utilisée pour récupérer les métadonnées. Si ces valeurs ne sont pas exactement identiques, les données contenues dans la réponse ne doivent pas (MUST NOT) être utilisées.

Dernière mise à jour le