OIDC access/refresh token changes with OIDC OP v4?

[Wessel, Keith]

Hi, Henri,

Thanks for the thoughts on this. Yes, we changed from DefaultLifeTime to DefaultTimeout and also added DefaultTokenChainLifetime last year.

The relying party override for this mobile app is:
                    <ref bean="OIDC.SSO" />
                    <ref bean="OIDC.UserInfo"/>
                    <bean parent="OAUTH2.Token"
                        p:issueIdTokenViaRefreshToken="true"
                        p:accessTokenLifetime="P1D"
                        p:iDTokenLifetime="P1D"
                        p:refreshTokenChainLifetime="P365D"
                        p:refreshTokenTimeout="P365D" />
                    <bean parent="OAUTH2.Revocation"
                        p:revocationLifetime="P365D" />
                    <ref bean="OAUTH2.Introspection"/>

Do you see anything wrong there? We're not getting any warnings in the logs about the configuration.

Keith

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Henri Mikkonen
Sent: Thursday, August 22, 2024 1:12 AM
To: users at shibboleth.net
Subject: Re: OIDC access/refresh token changes with OIDC OP v4?

Hi Keith,

On 22.8.2024 3.55, Wessel, Keith via users wrote:
> We (finally) upgraded to IdP v5 last week, and all went very well aside from some pesky token issues with a mobile app that has long-lived access tokens and extremely long-lived refresh tokens. Same app I've run into issues and talked about here on the list before. We're seeing:
> 
> [net.shibboleth.idp.plugin.oidc.op.userinfo.profile.impl.ParseAccessToken:126] - Profile Action ParseAccessToken: Unable to parse/decode token for validation
> 
> Just before that in the log, we see the IdP successfully retrieving the correct data sealer key version to decode the token. But then it fails to decode.

As the data sealer seems to be correct, then the output above is 
probably caused by the expired access token. The current implementation 
cannot describe the cause why the decoding failed. The plan is to 
improve it though, the following JIRA issue is related:

https://urldefense.com/v3/__https://shibboleth.atlassian.net/browse/JOIDC-181__;!!DZ3fjg!6rv_jHgwmR7n6TulS-KqYEkfPmh0ZF5sjAzahukacduBdBcY8IJwAAxCTkGeEzhzgn0VygcVuj9bnZXojrLVDfz-Gcg8iQ$ 

> I know that some new functionality is available in 4.1.0 for custom refreshtoken encoding/decoding, but I assume that left at the defaults, this is unchanged from previous versions.

Indeed, the default configuration should be similar to what you had with 
IdP4/OP3.

> Did anything change between v3 and v4 of the plugin that could have caused our IdP to no longer be able to decode these tokens?

At least not on purpose. We did quite a lot of code cleanup regarding 
handling of null/non-null values, but we have tests that verify that 
even the tokens from OPv2 era should still be compatible.

> Furthermore, some users are reporting that they have to sign back in multiple days in a row. So, it's almost as if the refresh tokens are no longer being honored at all.

One idea: do you set the refresh token timeout via oidc.properties or 
via relying party configuration? Regarding properties, OP4 doesn't wire 
the previously existing property ending with ".defaultLifetime" anymore. 
It was deprecated in OP3.3 and removed in OP4, as mentioned in the 
release notes. The logs warn about it too and hint that you need to use 
'idp.oidc.refreshToken.defaultTimeout' instead.

BR,
Henri.
-- 
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!6rv_jHgwmR7n6TulS-KqYEkfPmh0ZF5sjAzahukacduBdBcY8IJwAAxCTkGeEzhzgn0VygcVuj9bnZXojrLVDfzly9cVMw$ 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net