Jeton daccès url

la demande de jeton d’accès est valide, le serveur d’autorisation doit générer un jeton d’accès (et un jeton d’actualisation facultatif) et les renvoyer au client, généralement avec certaines propriétés supplémentaires concernant l’autorisation.

La réponse avec un jeton d’accès doit contenir les propriétés suivantes :

• (obligatoire) La chaîne de jeton d’accès telle qu’émise par le serveur d’autorisation.
• (obligatoire) Le type de jeton dont il s’agit, généralement simplement la chaîne « Bearer ».
• (recommandé) Si le jeton d’accès expire, le serveur doit répondre avec la durée pour laquelle le jeton d’accès est accordé.
• (facultatif) Si le jeton d’accès expire, il est utile de renvoyer un jeton d’actualisation que les applications peuvent utiliser pour obtenir un autre jeton d’accès. Toutefois Les jetons émis avec l’octroi implicite ne peuvent pas recevoir un jeton d’actualisation.
• (Facultatif) Si l’étendue accordée par l’utilisateur est identique à celle demandée par l’application, ce paramètre est facultatif. Si l’étendue accordée est différente de l’étendue demandée, par exemple si l’utilisateur a modifié l’étendue, ce paramètre est obligatoire.

Lorsqu’il répond avec un jeton d’accès, le serveur doit également inclure l’en-tête HTTP supplémentaire pour s’assurer que les clients ne mettent pas en cache cette demande.

Par exemple, une réponse de jeton réussie peut ressembler à ce qui suit :

HTTP/1.1 200 OK Content-Type : application/json Cache-Control : no-store { « access_token » :"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3 », « token_type » :"Bearer », « expires_in » :3600, « refresh_token » :"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk », « scope » :"create » }

Jetons d’accès

Le format des jetons OAuth 2.0 Bearer est en fait décrit dans une spécification distincte, la RFC 6750. Il n’y a pas de structure définie pour le jeton requis par la spécification, vous pouvez donc générer une chaîne et implémenter des jetons comme vous le souhaitez. Les caractères valides dans un jeton au porteur sont alphanumériques, et les caractères de ponctuation suivants :

-._~+/

Une implémentation simple des jetons au porteur consiste à générer une chaîne aléatoire et à la stocker dans une base de données avec les informations associées sur l’utilisateur et la portée, ou les systèmes plus avancés peuvent utiliser des jetons auto-encodés où la chaîne de jeton elle-même contient toutes les informations nécessaires.

Si

la demande de jeton d’accès n’est pas valide, par exemple si l’URL de redirection ne correspond pas à celle utilisée lors de l’autorisation, le serveur doit renvoyer une réponse d’erreur.

Les réponses d’erreur sont renvoyées avec un code d’état HTTP 400 (sauf indication contraire sinon), avec et paramètres. Le paramètre sera toujours l’une des valeurs répertoriées ci-dessous.

• – Il manque un paramètre à la requête, donc le serveur ne peut pas donner suite à la requête. Il peut également être renvoyé si la demande inclut un paramètre non pris en charge ou répète un paramètre.
• – Échec de l’authentification du client, par exemple si la demande contient un ID client ou un secret non valide. Dans ce cas, envoyez une réponse HTTP 401.
• – Le code d’autorisation (ou le mot de passe de l’utilisateur pour le type d’octroi de mot de passe) n’est pas valide ou a expiré. Il s’agit également de l’erreur que vous rauriez si l’URL de redirection fournie dans l’octroi d’autorisation ne correspond pas à l’URL fournie dans cette demande de jeton d’accès.
• – Pour les demandes de jeton d’accès qui incluent une étendue (mot de passe ou client_credentials accords), cette erreur indique une valeur de portée non valide dans la demande.
• – Ce client n’est pas autorisé à utiliser le type de subvention demandé. Par exemple, si vous limitez les applications qui peuvent utiliser l’octroi implicite, vous renvoyez cette erreur pour les autres applications.
• – Si un type d’octroi est demandé et que le serveur d’autorisation ne le reconnaît pas, utilisez ce code. Notez que les types d’octroi inconnus utilisent également ce code d’erreur spécifique plutôt que le code ci-dessus.

Il existe deux paramètres facultatifs lors du renvoi d’une réponse d’erreur : . Ceux-ci sont destinés à donner aux développeurs plus d’informations sur l’erreur, et non à être montrés aux utilisateurs finaux. Cependant, gardez à l’esprit que de nombreux développeurs transmettront ce texte d’erreur directement aux utilisateurs finaux, peu importe à quel point vous les avertissez, c’est donc une bonne idée de s’assurer qu’il est au moins quelque peu utile aux utilisateurs finaux également.

Le paramètre ne peut inclure que des caractères ASCII et doit être une phrase ou deux au maximum décrivant le circonstance de l’erreur. Il s’agit d’un excellent endroit pour créer un lien vers la documentation de votre API pour obtenir des informations sur la façon de corriger l’erreur spécifique qui a été rencontrée.

L’intégralité de la réponse d’erreur est renvoyée sous la forme d’une chaîne JSON, similaire à la réponse réussie. Vous trouverez ci-dessous un exemple de réponse d’erreur.

HTTP/1.1 400 Bad Request Content-Type : application/json Cache-Control : no-store { « error » : « invalid_request », « error_description » : « Il manquait le paramètre 'redirect_uri' à la demande. », « error_uri » : « Voir la documentation complète de l’API à https://authorization-server.com/docs/access_token » }