Closed jmmv closed 1 year ago
Looking further into this, the problem is coming from the content of the ID token itself. When decoding it via jwt.io, I get:
{
"nickname": "jmmv",
"name": "some@email.address",
"picture": "gravatar URL",
"updated_at": "2023-02-15T14:10:56.330Z",
"iss": "https://dev-foobar.us.auth0.com/",
"aud": "some value",
"iat": 1676653285,
"exp": 1676689285,
"sub": "auth0|some value",
"sid": "some value",
"nonce": "ekkh3mqcD_NOZD2rpf7kFA"
}
and passing the base64-encoded token to CoreIdToken::from_str
results into the same error...
... and this is a dup of https://github.com/ramosbugs/openidconnect-rs/issues/23. Glad there is a feature to fix this!
Hello,
I'm trying to use this crate (version 2.5.0) against Auth0 and I'm running into some issues. It's possible that this is caused by me misusing the crate's API, but... the code I have so far is a direct copy/paste of the sample code in the documentation, so there may be an actual bug.
When I issue the
exchange_code
call to obtain an ID token right after I get a callback redirect, I get an error of typeRequestTokenError::Parse
. Here is the error message (first field of theParse
type):And then this is the content (second field of the
Parse
type) I got back from the server (tokens redacted):I suspect the problem is caused by the untyped
expires_in
field, but as far as I can tell, that's a valid reply from the server.Note that I had to explicitly capture the
Parse
error and turn the raw byte output from the server into a string to print it out. (It'd be nice if the defaultDebug
onParse
did this, as it was pretty annoying to decode the actual output I got from the server.)Could you advice? Am I really misusing something, or does the code in the crate need some extra type annotations for proper deserialization?
Thank you!