사용이 제한된 액세스 토큰
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
용도가 제한된 액세스 토큰은 요청 스푸핑 및 재생 공격으로부터 보호하여 메시지를 수신한 사용자가 작업을 수행할 수 있도록 보장합니다. 요청 매개변수에 고유한 토큰 매개변수를 추가하고 작업이 호출될 때 이를 확인하여 보호합니다.
토큰 매개변수는 특정 작업과 특정 사용자만 사용할 수 있는 키로 생성되어야 합니다. 요청된 작업을 수행하기 전에 토큰이 유효하고 사용자를 위해 생성한 토큰과 일치하는지 확인해야 합니다. 토큰이 일치하면 작업을 수행할 수 있으며 이후 요청에 대해 토큰이 무효화됩니다.
액세스 토큰은 HttpActionHandler의 url
속성의 일부로 사용자에게 전송해야 합니다. 예를 들어 애플리케이션이 http://www.example.com/approve?requestId=123
에서 승인 요청을 처리하는 경우 애플리케이션에 추가 accessToken
매개변수를 포함하고 http://www.example.com/approve?requestId=123&accessToken=xyz
로 전송된 요청을 리슨해야 합니다.
requestId=123
및 accessToken=xyz
조합은 미리 생성해야 하므로 accessToken
에서 requestId
에서 추론할 수 없습니다. requestId=123
만 있고 accessToken
이 없거나 xyz
가 accessToken
가 아닌 승인 요청은 모두 거부해야 합니다. 이 요청이 통과되면 향후 동일한 ID와 액세스 토큰을 사용하는 요청이 모두 거부됩니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-07-25(UTC)
[null,null,["최종 업데이트: 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."]]