Uncaught exception with the tokens produced by V1/V2 of the extension

This is exactly what I was hoping for. I like it. Thank you.

The bug causing the uncaught exception is fixed but some incompatibilities with legacy tokens remain due to consent refactoring before V3. A table describing this will be part of the release notes page for the OP plugin.

The table:

The bug causing the uncaught exception is fixed but some incompatibilities with legacy tokens remain due to consent refactoring before V3. A table describing this will be part of the release notes page for the OP plugin.

Honestly, Henri, I'd be okay with tokens from V2 not being backward compatible with V3 as long as that's documented somewhere. When my customers' refresh tokens stopped being recognized after the upgrade, it was a clue, and it fits perfectly with your above explanation. I realize that this was a transition from the extension to the plugin, and it's obvious that a lot changed. As long as tokens are backwards compatible moving forward, my opinion is that this particular issue can be resolved in additions to the upgrade documentation. If you all want to put the time into making V3 accept tokens from V2, go for it. It would probably benefit others, though nobody other than me has been complaining about it so far. As for me, I'm over that hump, and I suspect that a simple note on the upgrade page would make most people happy.

The summary of previous comments with some new remarks:
 
The use of access and refresh tokens generated by the previous versions (1.x-2.x) of the OIDC extension causes uncaught runtime exception in the back-end endpoints (token, userinfo). The exception is caused by the fact that the current (3.0.x) code is expecting cnsnt* -claim to be existing in the token claims set. It's an internal data structure which is encrypted inside the access and refresh tokens and is thus not visible to the RPs. The *cnsnt claim is a flag indicating whether the consent (i.e. attribute-release) flow has been run for the end-user during the OIDC authorize-flow. It was added for v3.0.0 of the plugin (see ), and the claim is always set, not depending on its value (i.e. consent flow being activated or not).
 
The tokens generated by the previous versions of the extension never contained cnsnt claim: back then the consent information was always stored into the two claims:

1. cnsntbl_claims (consentable claims) - the value “stolen” from the AttributeReleaseContext - which is internal to the consent flow.

2. cnsntd_claims (consented claims): still used when the configuration property _idp.oidc.encodeConsentInTokens_ is set

To fix this issue, probably the best way is just to modify TokenClaimsSet.isConsentEnabled() to handle also “legacy” tokens not having cnsnt claim at all. When that claim is absent, the method should deduce the result via other means. In principle the legacy tokens work in a very similar way as the current tokens, when _idp.oidc.encodeConsentInTokens_ property is enabled.