alignment of certification tests with OAuth 2.1

[Joseph Heenan]

I think it would be good to have a discussion about how the certification tests for OpenID Connect Core might align with https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04

The main, and possibly only, issue to consider is how to deal with PKCE being mandatory, except in the case where OIDCC is in use where it is ‘RECOMMENDED’ - as per https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.1 :

 Clients MUST use code_challenge and code_verifier and authorization
 servers MUST enforce their use except under the conditions described
 in Section 7.8.  In this case, using and enforcing code_challenge and
 code_verifier as described in the following is still RECOMMENDED.

and from section 7.8:

Clients MUST prevent injection (replay) of authorization codes into
the authorization response by attackers.  To this end, using
code_challenge and code_verifier is REQUIRED for clients and
authorization servers MUST enforce their use, unless both of the
following criteria are met:

*  The client is a confidential client.

*  In the specific deployment and the specific request, there is
   reasonable assurance for authorization server that the client
   implements the OpenID Connect nonce mechanism properly.

In this case, using and enforcing code_challenge and code_verifier is
still RECOMMENDED.

Note that for many situations (i.e. the googles/gitlab/githubs etc that let any registered user create an OAuth client) it’s essentially impossible to meet the ‘there is reasonable assurance for authorization server that the client implements the OpenID Connect nonce mechanism properly’ criteria, meaning PKCE is required even when using OIDC.

The obvious options I can think of here are:

1. Do nothing; current situation that servers are required to accept requests that don’t have PKCE continues
2. Align OP tests; all OP tests to send valid S256 PKCE, but it is permitted for the server to just ignore the PKCE parameters.
3. '2', but also align RP tests: to achieve interoperability (certified OP will work with certified RP), we would need to require clients to send valid PKCE in all requests
4. '3', but also add a test requiring the OP to reject invalid PKCE, i.e. ensuring that the OP actually does implement PKCE

(Note that certification has a test module that already requires that servers do not reject valid PKCE, so going with option '2' will not cause any existing passing OPs to fail.)

I am not in favour of option ‘1' as it results in server implementations that would otherwise mandate PKCE being required to implement an option where PKCE can be disabled, and I do not think it is good practice for certification to require servers to implement reduced-security options that they would not otherwise implement, as it has the potential to cause accidental reductions in security (i.e. similar reasoning to why we now don’t require OPs to support alg: none).

I’m in favour of going as close to option ‘4' as we feel we can - whilst the ‘nonce’ in OIDCC is a equivalent defence, it is reliant on the RP implementing the checks correctly, and if the RP does not implement correctly then the consequence is that the flow works but is insecure, and unfortunately our experience from the field is that a lot of RP implementations are low quality, and hence it is better for mitigations to be implemented on the authorization server. Using PKCE achieves this - for most cases, a poor implementation results in the flow not working as the server rejects requests with missing/incorrect PKCE (though there are small cases the client could get wrong that the server may not pickup, like poor choice of code_verifier values).

[Joseph Heenan]

Discussed again on today’s WG call.

George Fletcher suggested an option along the lines of the tests always sending PKCE if they are able to detect a server aligns with OAuth 2.1.

We ran out of time and agree to continue the discussion on another call.

[Michael Jones]

Our testing suite already checks that PKCE usage doesn't cause failures, which is good.

Requiring PKCE at the OP would break any RPs not using PKCE, which is the majority of them. This would be a breaking change, bifurcating our ecosystem, which would be a very bad thing.

Note that exactly so as not to bifurcate the OpenID Connect ecosystem, OAuth 2.1 does not require the use of PKCE when OpenID Connect is used. It can safely do this because OpenID Connect already includes different mitigations to the problems that PKCE prevents.

Therefore, there is nothing we need to do to align with OAuth 2.1.

‌

[Joseph Heenan]

Hi Mike

Note that exactly so as not to bifurcate the OpenID Connect ecosystem, OAuth 2.1 does not require the use of PKCE when OpenID Connect is used. It can safely do this because OpenID Connect already includes different mitigations to the problems that PKCE prevents.

I think we’re reading different things or interpreting them differently - my reading of https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-7.8 is that most OIDC providers (my reading is that, as their policies currently stand, the B2C providers at Microsoft, Google, Gitlab, Github and so on are all caught by this clause) MUST require PKCE for confidential clients even when OIDC is in use.

[Thomas Bellebaum]

Requiring PKCE at the OP would break any RPs not using PKCE, which is the majority of them. This would be a breaking change, bifurcating our ecosystem, which would be a very bad thing.

I would not require PKCE to be always enforced, but neither does OAuth 2.1. It just requires that it is enforced unless specific requirements are fulfilled. Why don’t we explicitly define that the test client must be handled as if it does not fulfill those requirements (which, according to my reading, should be the default assumption for any OAuth 2.1 Auth Server)? If the OP needs to support poorly written RPs, it may still do this with the right configuration. That just would not be part of the test.

Also, we are “just” talking about certification. I think it makes sense to only certify RPs which may handle the entirety of 2.1 from this point forth, as those will probably be expected to work with any OAuth 2.1 based OP.

[Joseph Heenan]

Thomas: Just to clarify your suggestion, I believe you are suggesting that:

a) The OP tests will always send PKCE

b) There would not be an OP test that tries a request without PKCE and expects it to fail

c) The RP tests would require the RP to send PKCE in all cases

Is that correct?

(By “poorly written RPs” did you mean ones that don’t send PKCE, or ones that don’t properly implement nonce?)

[Thomas Bellebaum]

Yes, that is correct. The reasoning for b) being that the OP under test should not, as mandated by OAuth 2.1, have “reasonable assurance […] that the client implements the OpenID Connect nonce mechanism properly.” just because the test suite originates from the OIDF.

Poorly written RPs = RPs not sending PKCE, for which the OP may loosen the PKCE requirement. You are right, I should have made that explicit.

[Joseph Heenan]

This presentation from the previous IETF meeting explains why PKCE is necessary in some flows (to prevent authorization code injection) even when using nonce:

https://datatracker.ietf.org/meeting/113/materials/slides-113-oauth-sessa-pkce-in-the-security-bcp-01

(In particular the table on page 4. Note that other content in that presentation is about the OAuth Security BCP, whereas this ticket is about OAuth 2.1, and I believe the two specs differ slightly in their language.)

[Joseph Heenan]

I think my latest suggestion is:

A. Update OIDCC RP tests so client is always required to send PKCE. [Or alternatively, as that would technically be a normative change, so that a warning about potential interoperability/security issues is issued if the client doesn’t send PKCE.]

B. Update OIDCC OP tests so that PKCE is always sent, except for a new test where a request is made without PKCE and a warning is issued that links to the relevant OAuth Security BCP text if the authorization succeeds.

‌

[Joseph Heenan]

I’m not sure the WG ever discussed my latest two suggestions. I would like to revisit this discussion in the working group, as this continues to be a pain point as more and more authorization servers require PKCE by default even when using OIDC, for the reasons given in https://datatracker.ietf.org/meeting/113/materials/slides-113-oauth-sessa-pkce-in-the-security-bcp-01 and because OAuth 2.1 requires them to do so unless “In the specific deployment and the specific request, there is reasonable assurance by the authorization server that the client implements the OpenID Connect nonce mechanism properly", which is a pretty high standard to achieve in reality and one that is not met on most authorization servers.

[Michael Jones]

We discussed this on the 7-Aug-23 Connect working group call. On one hand, it would not be good to change the Certification criteria for existing profiles in ways that would make existing certified implementations non-conformant, as that would bifurcate the ecosystem. On the other hand, we probably do want to provide a new certification path for servers that are trying to do the right thing,

One possibility is to create new OP and RP certification profiles called something like OP-Basic+OAuth2.1 and RP-Basic+OAuth2.1 that require functioning PKCE.

[Joseph Heenan]

Thanks Mike.

I think for OP we probably have no option but to create a new profile like you suggest.

As a step in the right direction, I think we can also immediately start issuing a warning if an RP is making a request without PKCE. This would not stop them certifying, but would make it clear that using PKCE is recommended these days. I think we can also issue a failure in the RP uses PKCE but gets something wrong that would cause it issues.

‌

[Michael Jones]

As discussed during the 21-Aug-23 in-person certification team meeting, we’re thinking that we should start this with just a new OP-Basic+PKCE profile. Joseph will also think about whether we would need an OP-Dynamic+PKCE profile.