[CUSTOMER] Impossible to refresh an expired JWT claim

[chibenwa]

Description

WHEN using an expired JWT claim Upon 401 TwakeMail blocks forever

Expected result

Once again, I expect correct error management:

1. TwakeMail can audit the token, realize it is expired and discard it.
2. TwakeMail when faced with a 401 error should discard current credentials and redirect to login page (when using OIDC, of the OIDC provider)

Current behavior

https://github.com/linagora/tmail-flutter/assets/6928740/3425d1b2-eb1c-4b94-b1cc-29f0b33c3c27

Apisix log:

2024/01/16 14:52:22 [error] 49#49: *65226939 [lua] openid-connect.lua:319: phase_func(): OIDC introspection failed: jwt signature verification failed: 'exp' claim expired at Wed, 10 Jan 2024 23:18:23 GMT, client: 10.233.66.36, server: _, request: "GET /.well-known/jmap HTTP/1.1", host: "jmap.avocat.fr", referrer: "https://e-mail.avocat.fr/"
2024/01/16 14:52:22 [warn] 49#49: *65226939 [lua] plugin.lua:1098: run_plugin(): openid-connect exits with http status code 401, client: 10.233.66.36, server: _, request: "GET /.well-known/jmap HTTP/1.1", host: "jmap.avocat.fr", referrer: "https://e-mail.avocat.fr/"
10.233.66.36 - - [16/Jan/2024:14:52:22 +0000] jmap.avocat.fr "GET /.well-known/jmap HTTP/1.1" 401 653 0.010 "https://e-mail.avocat.fr/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" - - - "http://jmap.avocat.fr"

Cc @guimard

[hoangdat]

Can I verify it on preprod? It also has the same configuration?

[hoangdat]

@guimard Maybe we forgot offline_access scope in configuration in env.file of front-end. Must be

OIDC_SCOPES=openid,profile,email,offline_access

/authorized

/token

[chibenwa]

True.

https://ci.linagora.com/linagora/lrs/saas/tools/helm-charts/tmail-frontend/-/blob/main/tmail-frontend/values.yaml#L109

holds the following value:

oidcScopes: openid,profile,email

So it should rather be:

oidcScopes: openid,profile,email,offline_access

Correct?

Ps @guimard what do you think about this?

[chibenwa]

But to be fairly honnest offline_access for a web application seems not necessary, and I feel like it's a hack to not implement correct error handling. I feel reluctant to accept such a solution and would like to get @guimard optinion.

[hoangdat]

@chibenwa, you can see in the response of /token, no refreshToken, so that why we can not handle the case of expiration. Yes, @guimard will help us more details.

[guimard]

But to be fairly honnest offline_access for a web application seems not necessary, and I feel like it's a hack to not implement correct error handling. I feel reluctant to accept such a solution and would like to get @guimard optinion.

It depends on what you want to do with web. If you want to follow Lemonldap session, then you have to detect when session is down (just to read expiration of access_token) and relaunch authentication.

If you want to stay active after session expiration, then you need offline_access

[chibenwa]

If you want to follow Lemonldap session, then you have to detect when session is down (just to read expiration of access_token) and relaunch authentication.

I bet this is what we want.

[chibenwa]

@chibenwa, you can see in the response of /token, no refreshToken, so that why we can not handle the case of expiration. Yes, @guimard will help us more details.

@hoangdat That's not an excuse for completly failing at doing anything and not managing the error.

In such case we should discard auth materials and re-initiate a connection to the OIDC provider?

[hoangdat]

Ahh, got your point.

[hoangdat]

@dab246 I changed from Queue Interceptor to Interceptor, retry request does not be blocked anymore. App can go to login page as normal. Debugging to find out why?.

[hoangdat]

Root cause: retry on onError is blocked by queue interceptor, the current one was not resolved but still try to get the new one and the new one also have the error too.