LinkedIn
Twitter
I'm sorry you're having trouble.
Seeing lot of interesting issues. Is it my mis-understanding of the usage?
Maybe. It works for me?
Simple Generate/validate is throwing below error.. Any suggestions?
{
"fault": {
"faultstring": "No Algorithm found in JOSE Header: policy(VJ-JWT)",
"detail": {
"errorcode": "steps.jwt.NoAlgorithmFoundInHeader"
}
}
}
It's not possible for me to diagnose this with the information you've given. If I saw that message, the first thing I would check is: is there an algorithm in the header of the JWT? And the way to do that is to decode it. As you know the JWT is just a dot-concatenated sequence of base6-encoded things. The header is the first piece. So to decode a JWT, just split the string by dots and then base64-decode the first part. That will retrieve the JSON of the header. Or, you can use an online tool like this one to do that work for you.
Just paste in the JWT that you provided to the VerifyJWT policy, and check to see if there is a proper header. The header should have _at least_ an alg claim and an enc claim. This is an example of what looks right.
You'll notice that the Decoded Payload in the above image is shown as ?ciphertext? and that's because.... it's not possible to "Decode" the encrypted payload of an encrypted JWT. It's encrypted! No tool can "decode" it; the only way to recover the payload is to decrypt it, which is a cryptographic operation, which requires the cryptographic key. I haven't provided the key, and anyway that tool does not support the dir algorithm, so that decoder tool will not be able to show you the payload.
1.Why does there is a restriction on OutputVariable?? Can't we use any other variable example- jwt.output?
I don't understand the question. What restriction are you referring to? What restriction is there on the OutputVariable? There is none that I know of.
2.General question say if we use a client id for a given claim while generating how do we validate it when req comes with only JWE
The way I would do it is, encode the clientid in the payload at generation time. At Verify time, after the verify succeeds, you will have a context variable with a name like
jwt.NAME_OF_VERIFY_POLICY.decoded.claim.clientid. Use a VerifyAPIKey policy passing THAT variable as the client id, to verify it.
<VerifyAPIKey name='VAPIKey-1'>
<APIKey ref='jwt.VJ-JWT.decoded.claim.clientid'/>
</VerifyAPIKey>
3.Side by Side Generate & validate works fine - silly
I don't understand this question, sorry.
Attached please find an example API proxy that shows how you can use Apigee to generate and verify an encrypted JWT using the "dir" (DirectKey) alg. Take note! This proxy uses a fixed direct key. In a real proxy you would want a cryptographically strong encryption key if you use the dir algorithm. Example invocation:
# generate curl -i $apigee_endpoint/ejwt-dir-demo/generate/t1 # copy output from above into a shell variable TOKEN=eyJ0e.... # verify curl -i $apigee_endpoint/ejwt-dir-demo/verify/t1 -d "jwt=$TOKEN"
Thankyou Dino for details.
1.PFA for the updated sample. Only change is modified to a different mechanism to send (instead of form param sending as Authorization header). Is there a spec driven to only send the req in form parm? Does it work in any other mechanism?
2.
==
The way I would do it is, encode the clientid in the payload at generation time. At Verify time, after the verify succeeds, you will have a context variable with a name like jwt.NAME_OF_VERIFY_POLICY.decoded.claim.clientid. Use a VerifyAPIKey policy passing THAT variable as the client id, to verify it.
==
Say we encoded client id in the payload at generation time
example->
Generation time we pass below client id
<Subject ref="verifyapikey.VA-ClientId.client_id"/>
During verification only JWE would be send and no other mechanism to fetch client_id how do we get client_id for the verification to pass & decode the variables..
Any other mechanisms or we should avoid client id with in the claim since we can't get the context variable.
3. Relates to 1 when we have Generate & Validate with in same flow to just test it works with same context variable..It comes down to understanding if it is just form param only then it clarifies all kind of confusions.
