![]() iat (Issued At): the time at which the JWT was issued.nbf (Not Before): the time before which the JWT must not be accepted.exp (Expiration Time): the expiration time on or after which the JWT must not be accepted.aud (Audience): the recipients that the JWT is intended for.sub (Subject): the principal that is the subject of the JWT.iss (Issuer): the principal that issued the JWT.But the ".decoded" variable names will be easier to use, easier to find, and always JSON.You can include custom fields in your jwt payload, but the spec names a few registered claims that are reserved for specific uses. The policy will continue to set variables with the "legacy" claim names. decoded variable names will always use the short claim names (no elaborations from "sub" to "subject"). Nevertheless we thought we could improve things for future adopters.Īs a result we've decided to employ a new naming convention for the variables set by the DecodeJWT and VerifyJWT policies. ![]() We could not change any of that behavior because there are systems running in production that depend on that behavior. An audience that included "A" and "B" was serialized as "". That's always a bad sign.Ī further complication is that the audience claim is an array, and it was serialized in a non-JSON form. It wasn't simple to explain (some claims get longer names and some don't). To retrieve the subject you needed to use ".subject" while to obtain the x5t you needed to use ".x5t". As a result, the execution on the "long names" was half done. However, this intention doesn't work very well with some registered claim names like "x5t" and "x5c", which correspond to "x.509 Certificate Thumbprint" and "x.509 Certificate Chain". "sub" transformed to "subject", "iss" transformed to "issuer", "exp" transformed to "expiry", and so on. This was originally intended as a "convenience" for the registered claims. In this case, the "audience" is a full english word despite the fact that the actual claim name is "aud". Note: there is no ".decoded" segment in that variable name. Previous versions of the DecodeJWT policy set variables like this: The VerifyJWT policy sets variables in the same way. You will need to JSON.parse() that or run it through jsonPath to retrieve an individual claim. If you would like to see the entire JSON payload then you can reference this variable: -json If the claim is "foo" and the DecodeJWT policy is named DecodeJWT-1, then the variable name is: .foo ![]() Having said that, after the DecodeJWT policy, you can find the claims in this context variable: .CLAIMNAME If this is not what you are doing - if you are not using DecodeJWT and VerifyJWT in concert, then you are probably doing it wrong, and you probably don't want to use DecodeJWT alone. ![]() There MAY BE a reason to decode a JWT with the DecodeJWT policy - to retrieve items from the header that may help determine which key to use to verify the signature in a subsequent VerifyJWT policy. Do not rely on, or trust, the claims that you receive from a DecodeJWT policy. That means that it might be a completely contrived JWT with an invalid signature. I highly suggest that you take care when doing this.ĭecodeJWT does not verify the JWT. ![]() I understand you are using the DecodeJWT policy, and you want to examine the decoded claims. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |