Planka originally supported only RS256, the default value set by
the openid-client library from Panva.
To provide more flexibility for clients in configuring their OIDC interactions
with various providers, we now allow passing a signature algorithm through
an environment variable.
This enhancement enables users to specify a preferred signature algorithm,
accommodating different OIDC provider requirements.
Some OIDC providers support signed UserInfo response, to enhance
security. The OIDC client should be free to ask for the user info
sgnature, however in certain situations (e.g egov applications)
where security matters, the OIDC providers might chose to enforce
this sugnature.
Planka was not supported signed UserInfo response, which resulted
in an misleading exception 'invalidCodeOrNonce'.
Introduce the proper configurations to parametrize the OIDC client,
and a dedicated exception to improve the developer experience.
Specifications:
"The UserInfo Claims MUST be returned as the members of a JSON
object unless a signed or encrypted response was requested
during Client Registration."
Planka used a default response_mode 'fragment', which is not supported by all
OIDC providers.
Planka supports only the Authorization Code flow. The default response mode
for the authorization code flow is 'query', meaning the authorization server
appends the authorization code to the redirect URI as a query parameter.
I have added two environment variables: one to use the default response mode
from the OIDC provider, and one to customize the response mode if needed.
Using the default response mode is recommended by the OIDC specification:
"This use of this parameter is NOT RECOMMENDED when the Response Mode that
would be requested is the default mode specified for the Response Type."
To avoid any breaking changes, I kept the default value as 'fragment'. Ideally,
the environment variable should be undefined by default.
The OIDC implementation merged in https://github.com/plankanban/planka/pull/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, is safer (due to direct involvement of the IDP in obtaining user information) 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] rfc-editor.org/rfc/rfc6749#section-5.1
lebaudantoine
NathanVss
Gavin Mogan
Maksim Eltyshev
HannesOberreiter
Smiley3112
Matthieu Bollot
Edouard
Balthasar Hofer
Lorenz Brun
gorrilla10101
SimonTagne