Debugging JWTs from OIDC integration?

[iamscottcab]

I'm attempting to setup an OIDC integration with another piece of software. The login flow on the Authelia side is fine.

The consuming software is throwing a 500 once ive logged in and performed the redirect because it can't find a particular key in my JWT (apparently). I don't have access to the server where the redirect goes and I was wondering if there was a log level that'd spit out the contents of an auth chain or if there was some other way I could intercept the jwt so that I could make sure it looked correct?

[james-d-elliott]

Trace will show the contents of the response only encoded in base64 for ease of logging, and the access request response (token endpoint) is a normative OIDC application/json response with the id token JWT in the id_token property, and the opaque access token in the access_token property.

You should inquire with the other applications developers about how to debug this, as it's unlikely to be possible to debug an issue they're having from the Authelia side, and the responses are valid according to the official OIDC conformance suites. The only potential issue you may be able to debug is them never requesting the token by missing requests to that endpoint which will be most evident with the missing Access Request logs.

[iamscottcab]

Thanks. I can see Authelia handling the requests properly so I wasn't overly worried about the tokens being wrong was just looking for a different avenue to debug the problem. Good to know the behaviour of trace though.

[james-d-elliott]

No worries. I'd ensure the request is making it to the token endpoint as DNS and/or routing is the most common issue.