search

FusionAuth / fusionauth-issues

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

Support PKCE for OpenID Connect Identity Providers #968

Closed jandillmann closed 3 years ago

jandillmann commented 4 years ago

Support PKCE for OpenID Connect Identity Providers

Problem

Some identity providers require a code challenge when utilizing the Authorization Code Grant. Public clients are susceptible to an authorization code interception attack, and to mitigate against the threat the use of Proof Key for Code Exchange (PKCE) is recommended. (RFC 7636)

FusionAuth currently does not support PKCE for identity providers, which means those identity providers can not be used with FusionAuth.

Solution

Add PKCE support for identity providers to enhance the security of the Authorization Code Grant and compatibility with more identity providers.

The RFC indicates the client SHOULD always send the additional PKCE parameters regardless if the server has implemented this extension. See Section 5, paragraph 2.

Alternatives/workarounds

  1. Request the IdP allow a client that has not provided the code_verifier request parameter (i.e. Do not require the client to use the PKCE extension).
  2. Use a SAML v2 IdP configuration to connect to the same IdP.
  3. If you are not using FusionAuth hosted login pages (themed pages) you could initiate the login out of band, complete the auth code exchange and then take the access token (assuming it is a JWT) and complete the FusionAuth login using the External JWT IdP.
  4. Don't use the IdP with FusionAuth. Sad.

Additional context

Forum post in the FusionAuth community

According to the RFC 7636, a server implementation may choose to not allow a client that has not provided the code_verifier.

5. Compatibility

Server implementations of this specification MAY accept OAuth2.0 clients that do not implement this extension. If the "code_verifier" is not received from the client in the Authorization Request, servers supporting backwards compatibility revert to the OAuth 2.0 [RFC6749] protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this specification, client implementations of this specification do not need to know if the server has implemented this specification or not and SHOULD send the additional parameters as defined in Section 4 to all servers.

Initially PKCE was presented as a way to further secure public clients. The RFC title is even named Proof Key for Code Exchange by OAuth Public Clients.

More recently it is also recommended even for use with confidential clients, and in the proposed OAuth 2.1 standard, PKCE is suggested to be required.

Related

https://github.com/FusionAuth/fusionauth-issues/issues/572 https://github.com/FusionAuth/fusionauth-issues/issues/942

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 4 years ago

Thanks @jandillmann this would be a good addition. I'm assuming you're referring to the OpenID Connect Identity Provider specifically?

jandillmann commented 4 years ago

Yes, this applies to OpenID Connect Identity Providers.

robotdan commented 4 years ago

If you're not using our hosted login pages (themed pages) a work around may be for you to perform the auth code exchange out of band and then use the External JWT IdP configuration to complete the login.

jandillmann commented 4 years ago

Thank you, I will look into this.

robotdan commented 4 years ago

Tested against FusionAuth and Keycloak - OIDC w/ PKCE default (if the client provides it), S256 required, none required.