Could not decode access_token with authelia

[TheEaterr]

Hey !

Thank you very much for all the work you're doing. I tried setting up your PR using authelia as a provider but the login flow failed with "Could not decode access_token" as error message.

It might be a configuration error on my end since @kosssi mentionned he was able to get it working.

Here are the logs :

vaultwarden | [2024-02-03 17:24:28.113][request][INFO] GET /identity/sso/prevalidate?domainHint=VaultWarden vaultwarden | [2024-02-03 17:24:28.116][response][INFO] (prevalidate) GET /identity/sso/prevalidate => 200 OK vaultwarden | [2024-02-03 17:24:28.158][request][INFO] GET /identity/connect/authorize?client_id=web&redirect_uri=htt vaultwarden | [2024-02-03 17:24:28.290][response][INFO] (authorize) GET /identity/connect/authorize?<data..> => 307 Temporary Redirect vaultwarden | [2024-02-03 17:24:28.365][request][INFO] GET /identity/connect/oidc-signin?code=authelia_ac_***** vaultwarden | [2024-02-03 17:24:28.366][response][INFO] (oidcsignin) GET /identity/connect/oidc-signin?<code>&<state> => 307 Temporary Redirect vaultwarden | [2024-02-03 17:24:28.857][request][INFO] GET /api/config vaultwarden | [2024-02-03 17:24:28.857][response][INFO] (config) GET /api/config => 200 OK vaultwarden | [2024-02-03 17:24:28.858][request][INFO] POST /identity/connect/token vaultwarden | [2024-02-03 17:24:29.037][vaultwarden::api::identity][INFO] User *** logged in successfully. IP: *** vaultwarden | [2024-02-03 17:24:29.037][response][INFO] (login) POST /identity/connect/token => 200 OK vaultwarden | [2024-02-03 17:24:29.224][request][INFO] GET /api/config vaultwarden | [2024-02-03 17:24:29.224][response][INFO] (config) GET /api/config => 200 OK vaultwarden | [2024-02-03 17:24:29.310][request][INFO] POST /identity/connect/token vaultwarden | [2024-02-03 17:24:29.311][vaultwarden::sso][ERROR] Impossible to read access_token: {"ErrorModel":{"Message":"Could not decode access_token: InvalidToken","Object":"error"},"ExceptionMessage":null,"ExceptionStackTrace":null,"InnerExceptionMessage":null,"Message":"Could not decode access_token: InvalidToken","Object":"error","ValidationErrors":{"":["Could not decode access_token: InvalidToken"]},"error":"","error_description":""} vaultwarden | [2024-02-03 17:24:29.312][vaultwarden::api::identity][ERROR] {"ErrorModel":{"Message":"Impossible to read access_token: {\"ErrorModel\":{\"Message\":\"Could not decode access_token: InvalidToken\",\"Object\":\"error\"},\"ExceptionMessage\":null,\"ExceptionStackTrace\":null,\"InnerExceptionMessage\":null,\"Message\":\"Could not decode access_token: InvalidToken\",\"Object\":\"error\",\"ValidationErrors\":{\"\":[\"Could not decode access_token: InvalidToken\"]},\"error\":\"\",\"error_description\":\"\"}","Object":"error"},"ExceptionMessage":null,"ExceptionStackTrace":null,"InnerExceptionMessage":null,"Message":"Impossible to read access_token: {\"ErrorModel\":{\"Message\":\"Could not decode access_token: InvalidToken\",\"Object\":\"error\"},\"ExceptionMessage\":null,\"ExceptionStackTrace\":null,\"InnerExceptionMessage\":null,\"Message\":\"Could not decode access_token: InvalidToken\",\"Object\":\"error\",\"ValidationErrors\":{\"\":[\"Could not decode access_token: InvalidToken\"]},\"error\":\"\",\"error_description\":\"\"}","Object":"error","ValidationErrors":{"":["Impossible to read access_token: {\"ErrorModel\":{\"Message\":\"Could not decode access_token: InvalidToken\",\"Object\":\"error\"},\"ExceptionMessage\":null,\"ExceptionStackTrace\":null,\"InnerExceptionMessage\":null,\"Message\":\"Could not decode access_token: InvalidToken\",\"Object\":\"error\",\"ValidationErrors\":{\"\":[\"Could not decode access_token: InvalidToken\"]},\"error\":\"\",\"error_description\":\"\"}"]},"error":"","error_description":""} vaultwarden | [2024-02-03 17:24:29.312][response][INFO] (login) POST /identity/connect/token => 401 Unauthorized

Do you have an idea what could be the cause of the problem ?

[Timshel]

Probably mean that the token is not in JWT format. If you are running the latest version it should not be an issue unless you activated SSO_ROLES_ENABLED or SSO_ORGANIZATIONS_INVITE.

[TheEaterr]

I am not using those options. I'm testing it using the latest image on docker hub, but maybe this is outdated ?

[Timshel]

Latest should be 1.30.2-1.

Will have a look to check if missed something.

[TheEaterr]

Yes that is what I am running

[Timshel]

I had a look at the logs. And it appears that the login was successful. And first call to the token endpoint return a 200: [2024-02-03 17:24:29.037][response][INFO] (login) POST /identity/connect/token => 200 OK vaultwarden

But when called again later on it fails. Si I'm thinking might be some issues with the expiration time.

To see more debug information you can run with:

LOG_LEVEL_OVERRIDE="
vaultwarden::api::identity=debug
vaultwarden::sso=debug
"

[TheEaterr]

I get those two additionnal messages :

[vaultwarden::sso][DEBUG] Redirection to https://vault.maoune.fr/sso-connector.html?code=authelia_ac_N-******-******_identifier%3Dundefined [vaultwarden::sso][DEBUG] No refresh_token present So there's definitely something weird going on, especially the undefined in the redirection URL seems weird to me

[Timshel]

Hey Found the error was not thinking of the right place, but had similar issue with Google and could debug it. (had some leftover of when I though the access_token was always in JWT format).

Just pushed the 1.30.2-2 version should be ready in ~1h.

Note, since you triggered the issue it means that you have no refresh_token so the session won't be extended even if the user is active. If you want to be able to extend it it appears it's possible with the offline_access scope (cf). Would need to be added to SSO_SCOPES="email profile offline_access".

[avicoder]

Hey @Timshel can this SSO_SCOPES="email profile offline_access" also be applied to google auth?

[TheEaterr]

It works out of the box with the new version and I was also able to make it work with the old one by adding the offline_access scope to both authelia and vaultwarden (I also had to add the vaultwarden audience to the vaultwarden client (https://www.authelia.com/configuration/identity-providers/open-id-connect/#audience).

So thank you very much for all the work you're doing !

[TheEaterr]

Hey reopening the issue because I tried using org mapping and it doesn't work (makes sense since it is trying to decode the access token, which is not a JWT with authelia). From my understanding there is nothing in the spec saying that the access token could be a JWT (although real world implementations seem to disagree), and additional claims should be gotten either through the ID token or the user info endpoint. Here is an issue on another implementation solving the same kind of issue : https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OpenIDConnect/+/965852

What I feel would be most logical when getting additional claims would be to first check if they are in the ID token, then check if the access token is a JWT (if yes decrypt it and check if it has the claim) and finally request the info in user_info endpoint. What do you make of this ?

[TheEaterr]

Just realized this is actually the same issue as #26

[Timshel]

Hey, Yes there is another issue open on the subject: https://github.com/Timshel/vaultwarden/issues/26. I though on it and as you mention the spec only mandate JWT format for the IdToken so I will probably make the switch to IdToken at first and depending on feedback I'll see if I add the different fallback.

[Timshel]

Hey, Pushed the 1.30.2-4 (still building) which switch to reading Roles and Groups from the Id token instead of the Access-token.

[TheEaterr]

It works now ! Thank you very much