場合によっては、実行時に Apigee で API 呼び出しを処理している間に、アクセス トークンに関連付けられたメタデータを API プロキシで更新したいことがあります。これを可能にするために、Apigee はトークン属性を取得および設定するためのポリシーを提供しています。詳細については、Get OAuth V2 Info ポリシーと Set OAuth V2 Info ポリシーをご覧ください。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-18 UTC。"],[[["\u003cp\u003eThis content covers OAuth access tokens, refresh tokens, and authorization codes generated and managed by Apigee and Apigee hybrid.\u003c/p\u003e\n"],["\u003cp\u003eApigee attaches metadata to OAuth artifacts upon generation, including details like expiration time, associated app/developer, and other relevant information.\u003c/p\u003e\n"],["\u003cp\u003eCustom attributes can be added to access tokens or authorization codes using the \u003ccode\u003e<Attributes>\u003c/code\u003e element in the OAuthV2 policy, allowing for the inclusion of arbitrary data.\u003c/p\u003e\n"],["\u003cp\u003eDuring runtime verification, Apigee populates context variables with token information, including any custom attributes, accessible via \u003ccode\u003eaccesstoken.{custom_attribute}\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eAPI proxies have the ability to update the metadata of an access token at runtime using the "Get OAuth V2 Info" and "Set OAuth V2 Info" policies provided by Apigee.\u003c/p\u003e\n"]]],[],null,["# Customizing Tokens and Authorization Codes\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nAbout token and authorization code metadata\n-------------------------------------------\n\nApigee generates OAuth access tokens, refresh tokens, and authorization codes, and\ndispenses them to authenticated apps. At generation time, Apigee stores those tokens and codes.\nLater, when Apigee receives inbound API requests bearing these tokens or codes, Apigee uses the\nstored information to authorize the requests.\n\nWhen Apigee generates these OAuth artifacts, it also attaches metadata to the token or code. For\nexample, an access token is associated to name/value pairs that define expiration time, the\nassociated app and developer, and other information.\n\nThe JSON representation of an Apigee access token looks like the following: \n\n```transact-sql\n{\n \"issued_at\" : \"1372170159093\",\n \"application_name\" : \"ccd1803b-b557-4520-bd62-ddd3abf8e501\",\n \"scope\" : \"READ\",\n \"status\" : \"approved\",\n \"api_product_list\" : \"[Product1,Product2]\",\n \"api_product_list_json\" : [\"Product1\", \"Product2\"],\n \"expires_in\" : \"3599\", //--in seconds\n \"developer.email\" : \"joe@weathersample.com\",\n \"organization_id\" : \"0\",\n \"refresh_token\" : \"82XMXgDyHTpFyXOaApj8C2AGIPnN2IZe\",\n \"client_id\" : \"deAVedE0W9Z9U35PAMaAJYphBJCGdrND\",\n \"access_token\" : \"shTUmeI1geSKin0TODcGLXBNe9vp\",\n \"organization_name\" : \"apifactory\",\n \"refresh_count\" : \"0\"\n}\n```\n\nAdding custom attributes to OAuth tokens and authorization codes\n----------------------------------------------------------------\n\nSometimes it's useful to attach custom metadata to an access token. For example, you might wish\nto add a user name, group memberships or roles for a user, a customer ID, a session identifier,\nor other arbitrary information to a token. In Apigee, these data are called \"custom\nattributes.\" Subsequently, when the token is verified within the scope of an API request, that\ndata is made available to the API proxy via context variables. An API proxy could make\nfine-grained authorization or routing decisions based on the custom data that is attached to the\ntoken.\n\nTo attach arbitrary data to a token, use the `\u003cAttributes\u003e` element in\n[the OAuthV2 policy](/apigee/docs/api-platform/reference/policies/oauthv2-policy). You can\nspecify the name and value of the custom attribute. For example, here is a\npolicy configuration that generates a token and attaches a custom attribute called \"tenant_list\"\nto the token: \n\n```carbon\n\u003cOAuthV2 name=\"GenerateAccessToken\"\u003e\n \u003cOperation\u003eGenerateAccessToken\u003c/Operation\u003e\n \u003cExpiresIn\u003e600000\u003c/ExpiresIn\u003e\n \u003cGenerateResponse /\u003e\n \u003cSupportedGrantTypes\u003e\n \u003cGrantType\u003eclient_credentials\u003c/GrantType\u003e\n \u003c/SupportedGrantTypes\u003e\n \u003cGrantType\u003erequest.queryparam.grant_type\u003c/GrantType\u003e\n \u003cAttributes\u003e \n \u003cAttribute name=\"tenant_list\" ref=\"tenant_list_retrieved_from_external_service\" display=\"false\"/\u003e\n \u003c/Attributes\u003e\n\u003c/OAuthV2\u003e\n```\n\nYou can specify multiple custom attributes, and you can attach them implicitly to either an\nauthorization code (`\u003cOperation\u003eGenerateAuthorizationCode\u003c/Operation\u003e`) or\na token (`\u003cOperation\u003eGenerateAccessToken\u003c/Operation\u003e`) at the time of\ngeneration.\n\nWhen `display` is set to `true` (the default), custom attributes are\nreturned in the response, where they may be viewable by the app, or passed on to the end user.\nWhen `display` is set to `false`, custom attributes are stored in the data\nstore, but are not returned in the response message. In either case, the custom data is available\nto the policies within the API Proxy, after the token has been verified.\n\nFor more information about the `display` option, see\n[Displaying or hiding custom attributes in the response](/apigee/docs/api-platform/reference/policies/oauthv2-policy#attributesattribute-displayingorhidingcustomattributesintheresponse).\n\nGetting custom access token attributes at runtime\n-------------------------------------------------\n\nWhen there is a call to [`OAuthV2/VerifyAccessToken`](/apigee/docs/api-platform/reference/policies/oauthv2-policy),\nApigee verifies the token by looking it up in the token store. Apigee then populates a\nset of context variables containing information about the token. These include:\n\n- `organization_name`\n- `developer.id`\n- `developer.app.name`\n- `client_id`\n- `grant_type`\n- `token_type`\n- `access_token`\n- `issued_at`\n- `expires_in` //--in seconds\n- `status`\n- `scope`\n- `apiproduct.name*`\n\nIf there are any custom attributes on the token, those custom attributes are made available in\na context variable with the name `accesstoken.{custom_attribute}`. For example,\nsuppose a token is issued from the policy shown above. After verifying such a token, there would\nbe an additional context variable named `accesstoken.tenant_list`, containing the\nvalue that was stored at the time the token was generated.\n\nPolicies or conditions can then refer to these variables and modify behavior based on the\nvalues stored within.\n\nSetting and updating custom attributes at\nruntime\n-------------------------------------------------\n\nIn some situations, you will want your API Proxy to update the metadata associated to an\naccess token at runtime while an API call is being processed on Apigee. To help with this,\nApigee provides policies for getting and setting token attributes. For more information, see\n[Get OAuth V2 Info\npolicy](/apigee/docs/api-platform/reference/policies/get-oauth-v2-info-policy) and [Set OAuth\nV2 Info policy](/apigee/docs/api-platform/reference/policies/set-oauth-v2-info-policy).\n\n\nIn each of these policies, the `AccessToken` element should refer to a variable that\ncontains the access token."]]