OAuth authentication has no way to intercept the Token request

[Menighin]

Is your feature request related to a problem? Please describe.

I'm trying to implement OAuth authentication with PKCE.
The PKCE part requires that I send a code_verifier with the token request but this doesn't seem to be possible. I couldn't find anyway of intercepting the Token Request in order to put the code_verifier. As far as I understood, AspNetCore automatically get the authorization code and request for a token with it, all under the hood.

Describe the solution you'd like

To have an event like OnAuthorizationCodeReceived like we do on the OpenId middleware. Or maybe an even more specific, something like OnRequestForToken.

Describe alternatives you've considered

Implement all from scratch or use a 3rd party lib (any recomendations?)

Additional context

I'm trying to implement following this tutorial that uses OpenId. I couldn't find anything like the OnAuthorizationCodeReceived event on the OAuth so I'm stuck in a scenario where I request for authorization with code_challenge but I can't get the token because I can´t find a way to put the code_ verifier in the request.

Thanks!

[Tratcher]

The recommendation for customizing the code exchange is to derive from OAuthHandler and override ExchangeCodeAsync. E.g. https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers/blob/af1e3373cf00e82b186ea2a4bba0696d476b0dff/src/AspNet.Security.OAuth.Fitbit/FitbitAuthenticationHandler.cs#L64

[Menighin]

Thanks Tratcher! That indeed seems like a more concise and smart way of doing it :)
Still think it would be nice to have and event on this step though!

[Menighin]

@Tratcher I was giving this a try and I'm kinda stuck with one thing:
I must create a new code_verifier for each request. Meaning that this is dynamic and not an option of the AuthenticationHandler. This code_verifier is created before the challenge request (right now I have override the HandleChallengeAsync and put the logic there). Later on, when I get the authorization code on the ExchangeCodeAsync and will request for the token, how can I get the same code_verfier I used before?

I have tried setting the code_verifier as a private property of my CustomOAuthHandler but when the execution comes to ExchangeCodeAsync the property is not defined. I'm assuming then that AspNetCore is not using the same instance of my CustomAuthenticationHandler for every step of the proccess, correct?

Could you point me in some direction? Thanks!

[Tratcher]

The only way to fully round trip data is via the AuthenticationProperties collection that gets serialized into the State field.

[Menighin]

But is it request-safe? I mean, imagine I have two users loging in the app. For one I generate the code_verifier a1 and for the other b1. When retrieving the code_verifier from the State will I always get the correct one for that flow?

[Tratcher]

Yes, the auth properties and state are unique per login.

[Menighin]

@Tratcher I'm sorry but I think I didn't understand. What I did was simply extending OAuthOptions with my custom options that holds a CodeVerifier property. Then on the HandleChallengeAsync I set it and on the ExchangeCodeAsync I use it to get the Token.

The problem is that, from my tests, this is not "request-safe". I started two login flows in parallel and the wrong CodeVerifier was sent to a Token Request.

In the print below I'm running the Login twice. The first run you see the CodeVerifier was null and it was set to a value. On the second run, the CodeVerifier was already set to the previous value and is overriden, indicating that this is not "request-safe":

The way I'm using the CodeVerifier on the ExchangeCodeAsync is simply (wrong):

Could you elaborate, maybe with some code example, of what you meant?

Thanks a lot!

[Menighin]

Searching more here, I think you were refering to the state property set on te BuildChallengeUrl step. This is sent to the authorization request but I can't find a way to get it on the ExchangeCodeAsync to desserialize and use. Plus, I don't know if the code_verifier should be sent there for security reasons...

[Tratcher]

Options? No, that is global. I said AuthenticationProperties, it's a per login collection available in most auth APIs. https://github.com/aspnet/AspNetCore/blob/eaf63a670dde3cbbbaa73fb88653f8e197fbe966/src/Security/Authentication/OAuth/src/OAuthHandler.cs#L210-L220

[Menighin]

lol, my bad... But anyway, I don't have any AuthenticationProperties in the ExchangeCodeAsync... Should I override HandleRemoteAuthenticateAsync altogether to pass it...? :s

[Menighin]

@Tratcher I was able to make it work overriding the HandleRemoteAuthenticaAsync to call a custom ExchangeCodeAsync that has an AuthenticationProperties as a parameter.
I really don't think this is a nice way to it. A feature to have some events in between would be great (like OpenId).

Besides that, I'm not a security expert and would like to ask you just one last thing:
The whole point of PKCE is to secure the communication in the OAuth flow by sending a code_challenge to the authorization server and, later on, a code_verifier so the authorization server can recompute the code_challenge and verify that it is a secure request.

The way I implemented this, using the AuthenticationProperties I'm passing the code_verifier "secured" in the state parameter along with the code_challenge in the authentication request.
This seems smelly to me because it sounds like someone could intercept the authorization request and get the code_verifier from the state parameter, invalidating the whole PKCE-thing.

So my question is: how secure is the state? I'm securing it by using the Options.StateDataFormat.Protect() method. Is it ok?

Thanks a lot for your help!

[Tratcher]

AuthenticationProperties is fully encrypted by Options.StateDataFormat.Protect() when making the state field, it's as secure as your auth cookies.

[Menighin]

I will go with this solution then, thanks a lot for the support!