Openiddict-core: Authorization Code Grant with PKCE supported?

[johanndev]

I'm using OpenIddict on ASP.NET Core in conjunction with an angular app (and the angular-oauth2-oidc lib). Up until now, I've been using the Resource Owner Password Credentials Grant Type (I know, booooooo!!! ;) ) My original plan was to switch to the implicit flow, but while researching I've come across several sites that advise against using the implicit flow in a SPA (e.g. here) and instead use the Authorization Code Grant with PKCE (see here).
I haven't been able to find an OpenIddict sample or documentation which shows the usage of PKCE - Does the library support this feature? Can somebody give me some direction on how to proceed? :)

[kevinchalet]

PKCE is fully supported by the underlying OIDC server library (ASOS), with some additional security constraints added by OpenIddict:

• code_challenge_method=plain is deliberately not allowed. Only S256 is.

• No access token can be returned from the authorization endpoint when using PKCE. Concretely, this means that if you try to send a response_type=token/response_type=id_token token/response_type=code id_token token request with PKCE parameters present, it will be rejected.

To use PKCE with OpenIddict, you have nothing to configure: applications that support it simply have to send the code_challenge/code_challenge_method parameters as part of the authorization request. They will also have to send a code_verifier when redeeming the authorization code: if they don't, an error will be automatically returned.

[marcrib]

This is very confusing.

Many say that one should not use ROPC. But varios web frameworks (nodejs/ruby/others) use ROPC by default to work with JWT

Many say you should use Implicit Flow

Most small projects use SPA and Mobile client

[kevinchalet]

Many say you should use Implicit Flow

And now, some even say we should no longer use implicit for SPAs: https://auth0.com/blog/oauth2-implicit-grant-and-spa/

Wonderful world, isn't it? :trollface:

[ajfleming1]

Hello! I am using the fantastic library ASOS version 2.0.0-rc2-final to implement my very own OAuth 2.0 server but I am having trouble with supporting PKCE. The requests below result in being granted a valid token. The code_challenge parameter is equal to the hash of '12345'. As you can see, I can send in any arbitrary value as a code_verifier to the token endpoint without issue. I am not sure if the code_verifier parameter value is being validated or if I have made a mistake somewhere.

GET /authorize/?scope=user-read-birthdate&response_type=code&client_id=93650895-0bcd-4cc9-9141-5e85c178602d&redirect_uri=http%3A%2F%2Flocalhost%2Fcb&code_challenge=5994471abb01112afcc18159f6cc74b4f511b99806da59b3caf5a9c173cacfc5&code_challenge_method=S256 HTTP/1.1
Host: localhost:5001

POST /api/v1/token HTTP/1.1
Host: localhost:5001
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code={authCode}&code_verifier=xyzabc

[kevinchalet]

Hey,

I was not able to reproduce the issue you mentioned. Is your source code public so I can take a look? If not, you can reach me at [email protected] to share a repro privately.

Two things:

• 2.0.0-rc2-final is quite old now and is no longer supported. Consider migrating to the RTM version (2.0.0).

• The correct code_challenge for 12345 is not 5994471abb01112afcc18159f6cc74b4f511b99806da59b3caf5a9c173cacfc5. It should be something like WZRHGrsBESr8wYFZ9sx0tPURuZgG2lmzyvWpwXPKz8U (code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

[ajfleming1]

Thanks for the quick reply. I updated to 2.0.0 and I created the code_challengeusing the recommend method, but I am still seeing the same behavior (any code_verifier works on the token endpoint). My repo is public and available here - https://github.com/ajfleming1/OAuth. Thanks again!

[kevinchalet]

I'd say it's simply caused by a bug in your consent view, that doesn't flow all the authorization request parameters but just a limited list that doesn't include code_challenge/code_challenge_method: https://github.com/ajfleming1/OAuth/blob/master/OAuth/Views/Authorize/Index.cshtml#L42.

Since the second call to the authorization endpoint doesn't send the PKCE parameters, the authorization code is issued without any code_challenge attached and that's why code_verifier is ignored when validating the token request. Fix that and you should get an error similar to this one:

{
    "error": "invalid_grant",
    "error_description": "The specified 'code_verifier' parameter is invalid."
}

[kevinchalet]

Note: to make things more obvious, we could introduce a check in OpenIddict 3.0 to reject token requests that specify a code_verifier and an authorization code that doesn't have a challenge attached.

[ajfleming1]

Adding the hidden inputs on index.cshtml for code_challenge and code_challenge_methodenabled the desired behavior. Thank you!

[kevinchalet]

Good to hear!

Would you be interested in sending a PR to add the check I mentioned? It should be trivial to add and should ideally go there: https://github.com/openiddict/openiddict-core/blob/dev/src/OpenIddict.Server/OpenIddictServerHandlers.Exchange.cs#L1619

[ajfleming1]

I would love to do this and help out! I reckon I need to be a contributor to the repo?

[kevinchalet]

Being a regular contributor is definitely not necessary to send code contributions.

For that, simply fork the project (there's a button on the project's main page), clone your fork locally (e.g using GitHub Desktop), make your changes locally, commit and push them to your fork. When you're done, send a PR against this repo 😄

[ajfleming1]

Yes - okay. Done.

https://github.com/openiddict/openiddict-core/pull/903