search

FusionAuth / fusionauth-issues

FusionAuth issue submission project
https://fusionauth.io
91 stars 12 forks source link

signal support for PKCE in discovery document #1177

Open JuliusPC opened 3 years ago

JuliusPC commented 3 years ago

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:

Related

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 commented 3 years ago

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: https://github.com/FusionAuth/fusionauth-issues/issues/1029

JuliusPC commented 3 years ago

@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.