[[["易于理解","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-09-05。"],[[["\u003cp\u003eThis page describes the DecodeJWS policy, which is used in Apigee and Apigee hybrid environments to decode the header of a JSON Web Signature (JWS) without verifying its signature.\u003c/p\u003e\n"],["\u003cp\u003eThe DecodeJWS policy supports both attached and detached JWS payloads, working exclusively with the header portion of the JWS, and is compatible with any signing algorithm.\u003c/p\u003e\n"],["\u003cp\u003eBy using this policy, header information from the JWS is extracted and stored into flow variables, following the format \u003ccode\u003ejws.policy-name.header.header-name\u003c/code\u003e, with the payload stored in \u003ccode\u003ejws.policy-name.header.payload\u003c/code\u003e if present.\u003c/p\u003e\n"],["\u003cp\u003eThe policy can retrieve the JWS from a flow variable specified in the \u003ccode\u003e<Source>\u003c/code\u003e element, defaulting to \u003ccode\u003erequest.header.authorization\u003c/code\u003e with "Bearer" in the auth header, and will result in an error if it fails to decode the JWS or resolve the variable.\u003c/p\u003e\n"],["\u003cp\u003eWhen errors occur during execution or deployment, specific fault codes and variables are set, such as \u003ccode\u003esteps.jws.FailedToDecode\u003c/code\u003e for decoding issues or \u003ccode\u003eJWS.failed\u003c/code\u003e to indicate a general failure, which are designed to be handled through custom fault rules.\u003c/p\u003e\n"]]],[],null,["# DecodeJWS 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 the JWS header without verifying the signature on the JWS, and writes each header to a\nflow variable. This policy is most useful when used in concert with the [VerifyJWS policy](/apigee/docs/api-platform/reference/policies/verify-jws-policy),\nwhen the value of a header from within the JWS must be known before verifying the signature of the JWS.\n\nA JWS can have an *attached* payload, as in the form: \n\n```gdscript\nheader.payload.signature\n```\n\nOr, the JWS can omit the payload, called a *detached* payload, and be in the form: \n\n```text\nheader..signature\n```\n\nThe DecodeJWS policy works with both forms because it only decodes the header portion of the JWS.\nThe DecodeJWS policy also works regardless of the algorithm that was used to sign the JWS.\n\nSee [JWS and JWT policies overview](/apigee/docs/api-platform/reference/policies/jwt-policies-overview) for a detailed introduction\nand an overview of the format of a JWS.\n\nThis policy is an *Extensible policy* and use of this policy might have cost or\nutilization implications, depending on your Apigee license. For information on policy types\nand usage implications, 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. While this video is\nspecific to a JWT, many of the concepts are the same for JWS. \n\n### Sample: Decode a JWS\n\nThe policy shown below decodes a JWS found in the flow variable **var.JWS**. This\nvariable must be present and contain a viable (decodable) JWS. The policy can obtain the JWS from\nany flow variable. \n\n```gdscript\n\u003cDecodeJWS name=\"JWS-Decode-HS256\"\u003e\n \u003cDisplayName\u003eJWS Verify HS256\u003c/DisplayName\u003e\n \u003cSource\u003evar.JWS\u003c/Source\u003e\n\u003c/DecodeJWS\u003e\n```\n\nFor each header in the header portion of the JWS, the policy sets a flow variable named: \n\n```text\njws.policy-name.header.header-name\n```\n\nIf the JWS has an attached payload, then it sets the `jws.`\u003cvar translate=\"no\"\u003epolicy-name\u003c/var\u003e`.header.payload`\nflow variable to the payload. For a detached payload, `payload` is empty.\nSee [Flow variables](#flow-variables) for a complete list of the variables set by this policy.\n\nElement reference for Decode JWS\n--------------------------------\n\nThe policy reference describes the elements and attributes of the Decode JWS policy.\n\n### Attributes that\napply to the top-level element\n\n```text\n\u003cDecodeJWS name=\"JWS\" 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 management UI proxy editor\nwith a different, natural-language name.\n\n\\\u003cSource\\\u003e\n----------\n\n```gdscript\n\u003cSource\u003eJWS-variable\u003c/Source\u003e\n```\n\nIf present, specifies the flow variable in which the policy expects to find the JWS to\ndecode.\n| **Note:** By default, the JWS is retrieved from the variable **request.header.authorization** . In this case, Apigee looks for the JWS in the request Authorization header. If you pass the JWS 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 JWS in the Authorization header like this: \n|\n| ```text\n| curl -v http://52.200.92.187:9001/doctest-JWS/verify-rs256 -H \"Authorization: Bearer \u003cyour JWS\u003e\"\n| ```\n|\n| You can configure to policy to retrieve the JWS 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 JWS, the\n| policy returns an error.\n\n\nFlow variables\n--------------\n\nUpon success, the **Verify JWS** and **Decode JWS** policies set\ncontext variables according to this pattern: \n\n```gdscript\njws.{policy_name}.{variable_name}\n```\n\nFor example, if the policy name is `verify-jws`, then the policy will store\nthe algorithm specified in the JWS to this context variable:\n`jws.verify-jws.header.algorithm`\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\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=\"JWS Policy Errors\"\u003e\n \u003cStep\u003e\n \u003cName\u003eJavaScript-1\u003c/Name\u003e\n \u003cCondition\u003e(fault.name Matches \"TokenExpired\")\u003c/Condition\u003e\n \u003c/Step\u003e\n \u003cCondition\u003eJWS.failed=true\u003c/Condition\u003e\n \u003c/FaultRule\u003e\n\u003c/FaultRules\u003e\n```\n\n\u003cbr /\u003e"]]
