Jetons d'accès à usage limité
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les jetons d'accès à utilisation limitée offrent une protection contre le spoofing des requêtes et les attaques par rejeu. Ils garantissent que l'action est effectuée par l'utilisateur auquel le message a été envoyé. La protection est assurée en ajoutant un paramètre de jeton unique aux paramètres de la requête et en le vérifiant lorsque l'action est appelée.
Le paramètre de jeton doit être généré sous la forme d'une clé ne pouvant être utilisée que pour une action et un utilisateur spécifiques. Avant d'effectuer l'action demandée, vous devez vérifier que le jeton est valide et qu'il correspond à celui que vous avez généré pour l'utilisateur. Si le jeton correspond, l'action peut être effectuée et le jeton n'est plus valide pour de futures requêtes.
Les jetons d'accès doivent être envoyés à l'utilisateur dans la propriété url
de HttpActionHandler. Par exemple, si votre application traite les demandes d'approbation au niveau de http://www.example.com/approve?requestId=123
, vous pouvez envisager d'y inclure un paramètre accessToken
supplémentaire et d'écouter les requêtes envoyées à http://www.example.com/approve?requestId=123&accessToken=xyz
.
La combinaison requestId=123
et accessToken=xyz
est celle que vous devez générer à l'avance, en veillant à ce que accessToken
ne puisse pas être déduit de requestId
. Toute demande d'approbation avec requestId=123
et sans accessToken
ou avec un accessToken
différent de xyz
doit être refusée. Une fois la demande traitée, toute demande ultérieure avec le même ID et le même jeton d'accès devra également être rejetée.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/25 (UTC).
[null,null,["Dernière mise à jour le 2025/07/25 (UTC)."],[],[],null,["# Limited Use Access Tokens\n\nLimited-Use Access Tokens provide protection from request spoofing and [replay attacks](http://en.wikipedia.org/wiki/Replay_attack), ensuring that the action is performed by the user the message was sent to. Protection is achieved by adding a unique token parameter to the request parameters and verifying it when the action is invoked.\n\nThe token parameter should be generated as a key that can only be used for a specific action and a specific user. Before the requested action is performed, you should check that the token is valid and matches the one you generated for the user. If the token matches then the action can be performed and the token becomes invalid for future requests.\n\nAccess tokens should be sent to the user as part of the `url` property of the [HttpActionHandler](/workspace/gmail/markup/reference/types/HttpActionHandler). For instance, if your application handles approval requests at `http://www.example.com/approve?requestId=123`, you should consider including an additional `accessToken` parameter to it and listen to requests sent to `http://www.example.com/approve?requestId=123&accessToken=xyz`.\n\nThe combination `requestId=123` and `accessToken=xyz` is the one that you have to generate in advance, making sure that the `accessToken` cannot be deduced from the `requestId`. Any approval request with `requestId=123` and no `accessToken` or with a `accessToken` not equal to `xyz` should be rejected. Once this request gets through, any future request with the same id and access token should be rejected too."]]