signal support for PKCE in discovery document

[JuliusPC]

signal support for PKCE in discovery document

Problem

OAuth / OIDC clients relying on discovery document for enabling PKCE support may not use PKCE with FusionAuth.

Solution

Add supported challenge methods to /.well-known/openid-configuration as specified (although for OAuth) in RFC 8414. It may look like this:

"code_challenge_methods_supported": [
  "S256",
  "plain"
]

Additional context

Examples of Providers supporting this:

• Google
• IdentityServer
• Curity

Related

• Support OAuth2 metadata RFC (RFC 8414) #1029

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[robotdan]

We could add it to the OIDC discovery, or perhaps we should add the OAuth2 discovery and add it there since it is not part of the OIDC discovery spec.
Re: #1029

[JuliusPC]

@robotdan In my opinion you should handle OIDC discovery and OAuth 2 discovery in the same way: Both discovery urls should point to the same document.

Rationale behind this: OIDC is built on top of OAuth 2, so additions to OAuth 2 (like PKCE) can and should be used in combination with OIDC in case they do not contradict¹. If this were not the case, one should not use PKCE in combination with OIDC, because it is not mentioned in the OIDC spec 🙃️.

OAuth 2 discovery is based on OIDC discovery and even defines /.well-known/openid-configuration despite its name as valid discovery url for OAuth applications:

Some OAuth applications will choose to use the well-known URI suffix "openid-configuration". As described in Section 5, despite the identifier "/.well-known/openid-configuration", appearing to be OpenID specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.

---

¹) The deprecation of the implicit grant in OAuth 2.1 is such case.