OIDC: TechnicalException if OP supports signing alg 'none' among others

[Guillaume]

Hi,
I am using pac4j-oidc 5.2.1 in my app and one customer uses a LemonLDAP OpenId connect Provider, see their doc at https://www.lemonldap-ng.org/documentation/latest/idpopenidconnect.html

As you can see in their doc, the openid connect metadata contains the 'none' value for the key 'id_token_signing_alg_values_supported' but also other algorithms.
The lemonldap mailing list confirmed to that customer that the alg "none" is never used unless you explicitely configure it on a RP. So far, they respect the openid connect spec.

Given a default OidcClient with a default OidcConfiguration and such metadata, this provider fails to authenticate because when generating the TokenValidator, a TechnicalException is thrown at https://github.com/pac4j/pac4j/blob/5.2.x/pac4j-oidc/src/main/java/org/pac4j/oidc/profile/creator/TokenValidator.java#L58 when parsing these metadata

Latest pac4j-oidc throws the same Exception because by default allowUnsignedIdToken is false (which is good) so the if condition around this exception evaluates to true.

Could pac4j-oidc throw this blocking configuration error only if 'none' is the only value in the metadata ?
And if there are other algorithms just don't add the 'none' algorithm to the idTokenValidators if it is not explicitely allowed by the OidcConfiguration ?
Given the default configuration, the token validation will throw a BadJOSEException or alike if a token is sent unsigned because no signed alg could validate it.

In a word, I suggest that pac4j-oidc refuses unsigned idtoken if not explicitely allowed in the client but accepts a provider supporting it but not using it.

I also take this time to say Thanks for the amazing work on pac4j, very clean code, documented and easy to use api ! And for the continued support !

Best regards,

Guillaume

[Jérôme LELEU]

Hi,

I'm not sure on this: how can we know that if the OIDC provider exposes "none", it cannot be used?

Thanks.

Best regards,

Jérôme

--
You received this message because you are subscribed to the Google Groups "Pac4j users mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-users/34348b5f-a2c2-469d-bee2-b9b8f28b593an%40googlegroups.com.

[Guillaume]

Hi, thanks for your interest in this question.

How can we know if the OIDC provider exposes "none", it cannot be used? Well I don't think we can know, but nor can we guarantee it even if the OIDC provider does not expose "none".

That's why I suggest we keep the current behaviour of not adding the unsigned idtoken validator unless explicitely configured so in the pac4j OidcConfiguration and given the appropriate flow is used, but add all the other supported signed validators.

Regards

[Jérôme LELEU]

Hi,

Let's come back to the spec:

id_token_signing_alg_values_supported

REQUIRED. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT]. The algorithm RS256 MUST be included. The value none MAY be supported, but MUST NOT be used unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow).

"none" is not mandatory. The only recommendation is not to return an ID token from the authz endpoint if the provider supports "none".

It seems to me that setting "none" is an explicit choice from the OP accepting unsigned ID token.

Thus, the security concerns.

Hence the pac4j behavior: as soon as "none" is supported, it must explicitly be accepted on the pac4j side.

Thanks.

Best regards,

Jérôme

To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-users/e41fdcbf-7c66-4ec9-b2ed-f15f85564d13n%40googlegroups.com.

[Guillaume]

Hi Jérôme,

I don't think the change I'm suggesting is breaking any spec.

Pac4j already accepts idtokens from a provider with "none" in its id_token_signing_alg_values_supported metadata. It only requires that the OidcConfiguration has a preferred JWS algorithm, for example RS256, and it works.

I'm only suggesting a change that allow this behaviour but with all the signing alg values supported other than 'none'.

A concrete example may help.

Given these metadata :

{ ...

id_token_signing_alg_values_supported : [ 'none', 'RS256', 'HS512'],

...

}

I would like pac4j to use these 2 idtoken validators for this client :  'RS256', 'HS512', and 'none' only if the conditions of the spec you mention are met.

Best regards,

Guillaume

[Jérôme LELEU]

Hi,

OK. I get it now. You're right, it's better to keep other algorithms in any case and keep the "none" algorithm if it is explicitly allowed or exclude it if it is not allowed.

Would you mind submitting a PR to the master?

Thanks.

Best regards,

Jérôme

To view this discussion on the web visit https://groups.google.com/d/msgid/pac4j-users/82539eba-a04c-496d-b1a9-b249bc09bbe6n%40googlegroups.com.

[Guillaume]

Hi,

I'm glad we agreed on this change!

I'm motivated to prepare a PR for this, but it might take a bit of time, as it will be my first open-source contribution.

Thanks,

Guillaume