The OIDC implementation merged in #491 is flawed for multiple reasons.
It assumes that the access_token returned by the IDP has to be a JWT
parseable by the RP which is not the case [1].
Many major IDPs do issue tokens which are not JWTs and RPs should not
rely on the contents of these at all.
The only signed token which has a standardized format for direct RP
consumption is the OIDC
ID token (id_token), but this by default doesn't contain many claims,
especially role claims are omitted from them by default for size
reasons. To get these additional claims into the ID token, one needs an
IDP with support for the "claims" parameter.
It requires manual specification of the JWKS URL which is mandatory
in any OIDC discovery document and thus never needs to be manually
specified.
It also makes the questionable decision to use a client-side code flow
with PKCE where a normal code flow would be much more appropriate as
all user data is processed in the backend which can securely hold a
client secret (confidential client). This has far wider IDP support and
doesn't require working with ID tokens and claim parameters.
By using a server-side code flow we can also offload most complexity to
the server alone, no longer requiring an additional OIDC library on the
web client.
Also silent logout doesn't work on most IDPs for security reasons, one
needs to actually redirect the user over to the IDP, which then prompts
them once more if they actually want to log out.
This implementation should work with any OIDC-compliant IDP and even
OAuth 2.0-only IDPs as long as they serve and OIDC discovery document.
[1] https://www.rfc-editor.org/rfc/rfc6749#section-5.1
Lorenz Brun
Maksim Eltyshev
SimonTagne