[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-28。"],[[["\u003cp\u003eThe Decode JWT policy in Apigee and Apigee hybrid decodes a JWT without verifying its signature, which is useful for accessing claims before signature verification using the VerifyJWT policy.\u003c/p\u003e\n"],["\u003cp\u003eThis policy is algorithm-agnostic, meaning it can decode JWTs regardless of the signing algorithm used, and it is classified as a standard policy deployable to any environment type.\u003c/p\u003e\n"],["\u003cp\u003eThe JWT to be decoded can be sourced from any flow variable, but by default it is retrieved from the \u003ccode\u003erequest.header.authorization\u003c/code\u003e, and the output of the decoding process is written to context variables for use in subsequent policies or conditions.\u003c/p\u003e\n"],["\u003cp\u003eUpon successful decoding, the policy sets context variables such as \u003ccode\u003eclaim.audience\u003c/code\u003e, \u003ccode\u003edecoded.claim.name\u003c/code\u003e, and \u003ccode\u003eheader.algorithm\u003c/code\u003e, which provide details about the JWT's claims, decoded claims, and header information.\u003c/p\u003e\n"],["\u003cp\u003eIf a runtime or deployment error occurs, the policy returns specific fault codes and error messages, setting fault variables like \u003ccode\u003efault.name\u003c/code\u003e and \u003ccode\u003eJWT.failed\u003c/code\u003e to aid in error handling and debugging.\u003c/p\u003e\n"]]],[],null,["# DecodeJWT policy\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\n### What\n\nDecodes a JWT without verifying the signature on the JWT. This is most useful when used in\nconcert with the [VerifyJWT policy](/apigee/docs/api-platform/reference/policies/verify-jwt-policy), when the value of a claim from within the JWT must be known\nbefore verifying the signature of the JWT.\n\nThe JWT Decode policy works regardless of the algorithm that was used to sign the JWT.\nSee [JWS and JWT policies overview](/apigee/docs/api-platform/reference/policies/jwt-policies-overview) for a detailed introduction.\n\nThis policy is a *Standard policy* and can be deployed to any environment type. For\ninformation on policy types and availability with each environment type, see\n[Policy types](/apigee/docs/api-platform/reference/policies/reference-overview-policy#policy-types).\n\n### Video\n\n| **Note:** The following video shows the classic Proxy Editor in the\n| Apigee UI. Apigee is introducing a new version of the Proxy\n| Editor, which has a different design from the classic version shown in the video.\n\nWatch a short video to learn how to decode a JWT. \n\n### Sample: Decode a JWT\n\nThe policy shown below decodes a JWT found in the flow variable **var.jwt**. This\nvariable must be present and contain a viable (decodable) JWT. The policy can obtain the JWT from\nany flow variable. \n\n```gdscript\n\u003cDecodeJWT name=\"JWT-Decode-HS256\"\u003e\n \u003cDisplayName\u003eJWT Verify HS256\u003c/DisplayName\u003e\n \u003cSource\u003evar.jwt\u003c/Source\u003e\n\u003c/DecodeJWT\u003e\n```\n\nThe policy writes its output to context variables so that subsequent policies or conditions\nin the API proxy can examine those values. See [Flow variables](#flow-variables) for a\nlist of the variables set by this policy.\n\nElement reference for Decode JWT\n--------------------------------\n\nThe policy reference describes the elements and attributes of the Decode JWT policy.\n\n### Attributes that\napply to the top-level element\n\n```text\n\u003cDecodeJWT name=\"JWT\" continueOnError=\"false\" enabled=\"true\" async=\"false\"\u003e\n```\n\nThe following attributes are common to all policy parent elements.\n\n\\\u003cDisplayName\\\u003e\n---------------\n\n```text\n\u003cDisplayName\u003ePolicy Display Name\u003c/DisplayName\u003e\n```\n\nUse in addition to the name attribute to label the policy in the Apigee UI proxy editor\nwith a different, natural-language name.\n\n\\\u003cSource\\\u003e\n----------\n\n```gdscript\n\u003cSource\u003ejwt-variable\u003c/Source\u003e\n```\n\nIf present, specifies the flow variable in which the policy expects to find the JWT to\ndecode.\n| **Note:** By default, the JWT is retrieved from the variable **request.header.authorization** . In this case, Apigee looks for the JWT in the request Authorization header. If you pass the JWT in the Authorization header, you do not need to include the Source element in the policy; however, you **must** include **Bearer** in the auth header. For example, you would pass the JWT in the Authorization header like this: \n|\n| ```text\n| curl -v http://52.200.92.187:9001/doctest-jwt/verify-rs256 -H \"Authorization: Bearer \u003cyour JWT\u003e\"\n| ```\n|\n| You can configure to policy to retrieve the JWT from a form or query parameter variable or any\n| other variable. If the variable does not exist or if the policy otherwise can't find the JWT, the\n| policy returns an error.\n\n\nFlow variables\n--------------\n\nUpon success, the **Verify JWT** and **Decode JWT** policies set\ncontext variables according to this pattern: \n\n```gdscript\njwt.{policy_name}.{variable_name}\n```\n\nFor example, if the policy name is `jwt-parse-token` , then the policy will store\nthe subject specified in the JWT to the context variable named `jwt.jwt-parse-token.decoded.claim.sub`.\n(For backward compatibility, it will also be available in `jwt.jwt-parse-token.claim.subject`)\n\n\u003cbr /\u003e\n\nError reference\n---------------\n\n\nThis section describes the fault codes and error messages that are returned and fault variables that are set by Apigee when this policy triggers an error.\nThis information is important to know if you are developing fault rules to\nhandle faults. To learn more, see [What you need to know\nabout policy errors](/apigee/docs/api-platform/fundamentals/what-you-need-know-about-policy-errors) and [Handling\nfaults](/apigee/docs/api-platform/fundamentals/fault-handling).\n\n### Runtime errors\n\nThese errors can occur when the policy executes.\n\n### Deployment errors\n\nThese errors can occur when you deploy a proxy containing this policy.\n\n\u003cbr /\u003e\n\n\n### Fault variables\n\nThese variables are set when a runtime error occurs. For more information, see [What you need to know\nabout policy errors](/apigee/docs/api-platform/fundamentals/what-you-need-know-about-policy-errors).\n\n### Example error response\n\nJWT Policy Fault Codes\n\nFor error handling, the best practice is to trap the `errorcode` part of the error\nresponse. Do not rely on the text in the `faultstring`, because it could change.\n\n### Example fault rule\n\n```text\n \u003cFaultRules\u003e\n \u003cFaultRule name=\"JWT Policy Errors\"\u003e\n \u003cStep\u003e\n \u003cName\u003eJavaScript-1\u003c/Name\u003e\n \u003cCondition\u003e(fault.name Matches \"InvalidToken\")\u003c/Condition\u003e\n \u003c/Step\u003e\n \u003cCondition\u003eJWT.failed=true\u003c/Condition\u003e\n \u003c/FaultRule\u003e\n \u003c/FaultRules\u003e\n \n```\n\n\u003cbr /\u003e"]]