search

mitreid-connect / OpenID-Connect-Java-Spring-Server

An OpenID Connect reference implementation in Java on the Spring platform.
Other
1.47k stars 767 forks source link

Possible to use PKCE without client_secret? #1456

Open joegalley opened 5 years ago

joegalley commented 5 years ago

I'm trying to use PKCE with the authorization code flow. It seems like the auth code flow requires you to use HTTP Basic auth to send along client_id and client_secret (so you must store client_secret client-side somewhere). Is this true, or is it possible to use the auth_code/PKCE flow without having store client_secret in the code? On this page from Okta, it says 

Important: Unlike the regular Authorization Code Flow, this call does not require the Authorization header with the client ID and secret. This is why this version of the Authorization Code flow is appropriate for native apps.

so that makes it seem like it's possible to not need the client_secret in the auth_code flow.

However from my testing, it seems like MitreID requires the client_secret to be sent along. This would require the client_secret to be stored on the client. Now that the client_secret may be exposed, PKCE only protects the auth code itself. Given this, you would need to ensure that you don't use any other grants besides auth_code with PKCE going forward, because your cilent_secret may be exposed.

visweshwar commented 5 years ago

This as per the PKCE RFC. Please refer the link below https://tools.ietf.org/html/rfc7636#section-4.4.1

Upon receipt of the Authorization Code, the client sends the Access Token Request to the token endpoint. In addition to the parameters defined in the OAuth 2.0 Access Token Request (Section 4.1.3 of [RFC6749]), .....

joegalley commented 5 years ago

Interesting. I'm not well-versed on the design decisions behind OAuth2 but this sounds like that to use PKCE you must also store client_secret on the client. In effect PKCE may expose client_secret. Since current best practice says to use the auth_code grant with PKCE instead of the implicit grant, I guess it's more secure, but storing client_secret on a public client seems weird

joegalley commented 5 years ago

Under 8.5. Client Authentication it says

Secrets that are statically included as part of an app distributed to multiple users should not be treated as confidential secrets, as one user may inspect their copy and learn the shared secret. For this reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT RECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret, as this serves little value beyond client identification which is already provided by the "client_id" request parameter.

And https://oauth.net/2/pkce/ says

PKCE (RFC 7636) is a technique to secure public clients that don't use a client secret.

That sounds like PKCE was intended to not require client_secret?

visweshwar commented 5 years ago

Based on your application requirement or your security requirement you can optionally disable token authentication. Mitre supports that, so it's up to you..

image

Puneetsri commented 5 years ago

Hi, As i mentioned in issue #1455, client-secret seems to be mandatory in mitreid-connect implementation, and upper shown configuration does not really make it optional. I believe this (No authentication) is just a hook at UI level, but not really implemented at server level (or at least at /token level). Probably it means that we should extend the server with this possibility.

joegalley commented 5 years ago

Ok thanks @visweshwar and @Puneetsri for the explanations and help

bitti commented 4 years ago

This as per the PKCE RFC. Please refer the link below https://tools.ietf.org/html/rfc7636#section-4.4.1

If you follow the breadcrumps of references starting from this section you end up at https://tools.ietf.org/html/rfc6749#section-2.3. I think the decisive sentence there is

The client MUST NOT use more than one authentication method in each request.

Therefore providing both a client_secret and code_challenge/code_verifier should be an error.

AlexanderplUs commented 4 years ago

If you follow the breadcrumps of references starting from this section you end up at https://tools.ietf.org/html/rfc6749#section-2.3. I think the decisive sentence there is

All section 2.3 is for confidential client type and PKCE is for public client type - see https://tools.ietf.org/html/rfc6749#section-2.1. So it is not an error to use client_secret and code_challenge together. Such case is demonstrated in PKCE Example on the OAuth 2.0 Playground