3. Points de terminaison du protocole (Protocol Endpoints)
Le processus d'autorisation utilise deux points de terminaison du serveur d'autorisation (points de terminaison HTTP) :
- Point de terminaison d'autorisation (Authorization Endpoint) - Utilisé par le client pour obtenir l'autorisation du propriétaire de ressource via une redirection de l'agent utilisateur.
- Point de terminaison de jeton (Token Endpoint) - Utilisé par le client pour échanger une autorisation (Authorization Grant) ou un jeton de rafraîchissement (Refresh Token) contre un jeton d'accès (Access Token).
De plus, il existe un point de terminaison client (Client Endpoint) :
- Point de terminaison de redirection (Redirection Endpoint) - Utilisé par le serveur d'autorisation pour renvoyer des réponses contenant des informations d'autorisation au client via l'agent utilisateur du propriétaire de ressource.
Tous les points de terminaison ne sont pas utilisés dans tous les flux d'autorisation OAuth. Par exemple, le flux implicite (Implicit Grant) n'utilise pas le point de terminaison de jeton, tandis que le flux d'informations d'identification du propriétaire de ressource (Resource Owner Password Credentials Grant) n'utilise pas le point de terminaison d'autorisation.
Les URI des points de terminaison peuvent (MAY) inclure un composant de requête (<RFC3986> Section 3), mais ne doivent pas (MUST NOT) contenir un composant de fragment. Le serveur d'autorisation et le client doivent (MUST) ajouter des paramètres supplémentaires aux URI contenant les paramètres définis par cette spécification en utilisant le composant de requête ou le format application/x-www-form-urlencoded. Cependant, l'URI de redirection est exempté de cette exigence.
3.1. Point de terminaison d'autorisation (Authorization Endpoint)
Le point de terminaison d'autorisation (Authorization Endpoint) est utilisé pour interagir avec le propriétaire de ressource et obtenir l'autorisation. Le serveur d'autorisation doit (MUST) d'abord vérifier l'identité du propriétaire de ressource. La manière dont le serveur d'autorisation authentifie le propriétaire de ressource (par exemple, nom d'utilisateur et mot de passe, cookie de session) dépasse le cadre de cette spécification.
Les moyens par lesquels le client obtient l'autorisation du propriétaire de ressource (via une redirection ou directement) doivent être déterminés en fonction des capacités, des exigences et des considérations de sécurité du serveur d'autorisation. Lors de l'utilisation d'un flux basé sur la redirection, le serveur d'autorisation agit comme intermédiaire entre le client et le propriétaire de ressource via l'agent utilisateur (généralement un navigateur Web).
Lors de la communication avec le point de terminaison d'autorisation via la redirection HTTP, le serveur d'autorisation doit (MUST) exiger l'utilisation de TLS. L'URI du point de terminaison doit (MUST) être un URI absolu tel que défini par <RFC2616>. L'URI du point de terminaison ne doit pas (MUST NOT) inclure un composant de fragment.
Le point de terminaison d'autorisation ne nécessitant pas d'authentification du client, il peut être vulnérable à certaines failles de sécurité telles que :
- Le propriétaire de ressource ne peut pas authentifier le client et peut être trompé par un client malveillant.
- Le propriétaire de ressource ne peut pas authentifier le serveur d'autorisation et peut être trompé par un serveur d'autorisation malveillant.
Pour atténuer ces menaces, le serveur d'autorisation devrait (SHOULD) permettre au propriétaire de ressource de vérifier l'identité du client (voir Section 10.12) et utiliser TLS pour garantir l'authenticité du point de terminaison du serveur d'autorisation (voir Sections 1.6 et 10.9).
3.1.1. Type de réponse (Response Type)
Le point de terminaison d'autorisation (Authorization Endpoint) est utilisé pour prendre en charge plusieurs types de réponse, déterminés par le paramètre de demande response_type. La valeur du paramètre response_type est une liste sensible à la casse délimitée par des espaces utilisant uniquement des caractères ASCII [USASCII].
Les types de réponse d'extension peuvent (MAY) contenir des valeurs supplémentaires. Si le paramètre response_type contient une valeur non reconnue ou si une valeur est manquante, le serveur d'autorisation doit (MUST) renvoyer une réponse d'erreur telle que décrite dans la Section 4.1.2.1.
3.1.2. Point de terminaison de redirection (Redirection Endpoint)
Après avoir complété son interaction avec le propriétaire de ressource, le serveur d'autorisation redirige l'agent utilisateur du propriétaire de ressource vers le client. Le serveur d'autorisation redirige l'agent utilisateur du propriétaire de ressource vers l'URI de redirection (Redirection URI) enregistré du client.
L'URI du point de terminaison de redirection doit (MUST) satisfaire les exigences suivantes :
- Il doit (MUST) être un URI absolu tel que défini par
<RFC3986>Section 4.3. - L'URI de redirection ne doit pas (MUST NOT) inclure un composant de fragment.
Confidentialité des demandes de point de terminaison
Le point de terminaison de redirection (Redirection Endpoint) devrait (SHOULD) exiger l'utilisation de TLS lorsque les informations demandées ou échangées sont sensibles ou de valeur. Les informations d'identification du client et les jetons d'accès peuvent être inclus dans la réponse lors de la redirection, il est donc recommandé d'utiliser TLS (voir Sections 1.6 et 10.9).
Exigences d'enregistrement
Le serveur d'autorisation doit (MUST) exiger l'enregistrement de l'URI de redirection pour :
- Les clients publics (Public Client)
- Les clients confidentiels (Confidential Client) utilisant le type d'autorisation implicite (Implicit Grant Type)
Le serveur d'autorisation devrait (SHOULD) exiger l'enregistrement de l'URI de redirection pour tous les clients.
Le serveur d'autorisation devrait (SHOULD) permettre au client d'enregistrer plusieurs URI de redirection. Ne supposez pas qu'une partie des URI de redirection enregistrés ne correspondra pas.
Lorsque l'enregistrement de l'URI de redirection est requis, le serveur d'autorisation devrait (SHOULD) permettre l'enregistrement d'URI de redirection partiels. Dans ce cas, le serveur d'autorisation doit (MUST) valider l'URI de redirection complet fourni par le client à chaque demande (voir Section 3.1.2.3).
Configuration dynamique
Si aucun URI de redirection n'est enregistré, le client doit (MUST) inclure un URI de redirection dans chaque demande d'autorisation (en utilisant le paramètre redirect_uri).
Si un URI de redirection est enregistré et qu'aucun URI de redirection n'est inclus dans la demande d'autorisation, le serveur d'autorisation doit (MUST) utiliser l'URI de redirection enregistré.
Si un URI de redirection est inclus dans la demande d'autorisation, le serveur d'autorisation doit (MUST) vérifier que la valeur demandée correspond à au moins un des URI de redirection enregistrés.
Point de terminaison non valide
Si une erreur se produit lors de la validation de l'URI de redirection, le serveur d'autorisation doit (MUST) en informer le propriétaire de ressource et ne doit pas (MUST NOT) rediriger automatiquement vers l'URI de redirection non valide.
Contenu du point de terminaison
La demande de redirection peut contenir des informations sensibles telles que le code d'autorisation (Authorization Code) ou le jeton d'accès (Access Token), le client devrait (SHOULD) s'assurer que le point de terminaison de redirection ne divulgue pas d'informations à des tiers (autres que le propriétaire de ressource).
3.2. Point de terminaison de jeton (Token Endpoint)
Le point de terminaison de jeton (Token Endpoint) est utilisé par le client pour obtenir un jeton d'accès (Access Token) en présentant une autorisation (Authorization Grant) ou un jeton de rafraîchissement (Refresh Token). Le point de terminaison de jeton est utilisé avec tous les types d'autorisation sauf le type d'autorisation implicite (Implicit Grant Type) (où un jeton d'accès est émis directement depuis le point de terminaison d'autorisation).
L'emplacement du point de terminaison de jeton et la manière d'y accéder sont généralement décrits dans la documentation du service. L'URI du point de terminaison peut (MAY) inclure un composant de requête (<RFC3986> Section 3), mais ne doit pas (MUST NOT) contenir de paramètres supplémentaires. L'URI du point de terminaison ne doit pas (MUST NOT) inclure un composant de fragment.
Le point de terminaison de jeton doit (MUST) exiger l'utilisation de TLS. Le client doit (MUST) utiliser la méthode HTTP POST pour faire des demandes au point de terminaison de jeton.
Les paramètres inclus dans les demandes au point de terminaison de jeton doivent (MUST) être envoyés dans le corps de l'entité de la demande HTTP et doivent (MUST) utiliser le format application/x-www-form-urlencoded.
3.2.1. Authentification du client (Client Authentication)
Les clients confidentiels (Confidential Client) ou les autres clients qui ont reçu des informations d'identification du client doivent (MUST) s'authentifier auprès du serveur d'autorisation au point de terminaison de jeton. L'authentification du client est utilisée à des fins suivantes :
- Confirmer l'identité du client (basée uniquement sur l'identifiant du client). Ceci est important pour empêcher les clients confidentiels d'échanger un code d'autorisation non autorisé contre un jeton d'accès. Lorsque la transmission du code d'autorisation se fait via un canal non sécurisé, ou lorsque le serveur d'autorisation ne peut pas confirmer que le client a obtenu le code d'autorisation, le serveur d'autorisation doit (MUST) imposer l'authentification du client.
- Lier les jetons de rafraîchissement (Refresh Token) au client. Lorsque le jeton de rafraîchissement est lié au client, l'authentification du client empêche un autre client d'abuser d'un jeton de rafraîchissement compromis.
- Permettre au client de faire pivoter ses informations d'identification du client.
Le client ne doit pas (MUST NOT) utiliser plus d'une méthode d'authentification dans chaque demande. Les clients publics (Public Client) (clients sans informations d'identification du client) doivent (MUST) inclure l'identifiant du client dans les demandes envoyées au point de terminaison de jeton.
3.3. Portée du jeton d'accès (Access Token Scope)
Les points de terminaison d'autorisation et de jeton permettent au client de spécifier la portée (Scope) de la demande d'accès en utilisant le paramètre de demande scope. Le serveur d'autorisation informe ensuite le client de la portée du jeton d'accès émis en utilisant le paramètre de réponse scope.
La valeur du paramètre scope est exprimée sous forme d'une liste de valeurs de portée délimitées par des espaces, sensibles à la casse. La définition des valeurs de portée est laissée au serveur d'autorisation. Si des valeurs de portée sont définies, le serveur d'autorisation doit (MUST) documenter à la fois les portées demandées par le client et les portées réellement accordées.
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
Le serveur d'autorisation peut (MAY) documenter entièrement les valeurs de portée prises en charge. Le serveur d'autorisation peut (MAY) autoriser partiellement, refuser ou ignorer tout ou partie de la portée demandée par le client. Si la demande n'inclut pas le paramètre scope ou si celui-ci est vide, le serveur d'autorisation doit (MUST) rejeter la demande d'autorisation, appliquer une portée par défaut ou ignorer la portée demandée par le client. Le serveur d'autorisation ne doit pas (MUST NOT) répondre avec une portée vide.