The token passed does appear to be JWT, and using the token decoder shows an alg header of “RS256” and a typ of “JWT”. I created the token with both an audience and a scope. What am I missing, or some pointers on where to look next would be much appreciated.
Hey @ljhardy , checking the algorithm is the first check done by the SDK and it can fail in a variety of scenarios like the token being a non-JWT. Have you double-checked that:
The token is decoded correctly when you paste it in https://jwt.io
And that you are passing the write token to decode()? For example, make sure you strip the Bearer part from the Authorization header.
If none of them works, you can also try decoding the token separately with a script like this and see if it works:
Thanks. Jwt.io appears to decode the token correctly and debugging messages show the same token going into the programmatic authorization. I’ll try the php script decoder that you suggested.
Thanks for testing. That implies the token itself is good, and what’s failing on the API could be due to how the token is handled there.
You may need to compare how the API code is initializing the SDK, retrieving the Access Token and decoding it. If you can post the snippets here we can take a look too.
Thanks, interesting. The PHP decoder script replies that the JWT is valid, when I run it standalone and cut and paste in the token. When I run it “in-line” in the API itself, it replies that the alg header is missing. I have verified that it is the exact same token string. It must have something do with the context that I am using the token. I will debug some more and report back. Thanks again.
Well, it’s always the simple things. When I said, “the tokens are identical”, I should have said
“the tokens are identical EXCEPT for the enclosing quotes.” lol. Problem solved.