Oauth2 authentication erroring with "The oauth state was missing or invalid."

[atrauzzi]

I'm trying to use app.UseOAuthAuthentication(), however it seems to be having issues with the system I'm integrating with.

They have a system where links are clicked in their portal and users are directed to my application with the code already in-hand. I think in this sense, I'm beginning the oauth2 flow somewhat half way through, although it still abides by standards.

Is there any way to tell the middleware to not require a state parameter or is this something that needs to be added as an optional feature?

[atrauzzi]

FWIW, this seems similar, but the explanation offered by @Tratcher doesn't seem to fit my situation.

#1646

[Tratcher]

No, there's no built in support for remotely initiated logins. Your best bet for now is to fork UseOAuthAuthentication and adjust it as needed. That said, there may be additional security considerations for this scenario.

@blowdart have you run into this scenario before?

[blowdart]

No

[atrauzzi]

That's a long hierarchy of classes to have to include in a fork. Really it looks like I'll just be doing it to chop down a few security checks.

I've dealt with other oauth libraries in the past and I know when consuming other peoples' server implementations, they don't always get it right. Especially with oauth1, holy wow can that get ridiculous.

What these other libraries have done to make life easier for me though is to offer some flexibility during configuration.

I certainly am not advocating setting lenient defaults. I also really like being able to point a strong implementation at a server, have it fail and being able to say "you guys aren't compliant!".

But by the same token, most people literally don't care and I don't have the luxury of saying "well then we won't integrate with them!"

[brockallen]

There's nothing in OIDC or OAuth2 that defines token-server (aka IdP) initiated signin. The pattern is to send the user to a protected endpoint in the end app and have that trigger the normal signin workflow. WS-Fed and SAML2-P did support this, FWIW... but then, those aren't modern :)

[atrauzzi]

No, and I'm definitely not under any illusion that this is 100% in the spec. But it does highlight that there are going to be scenarios like this and the only thing stopping the middleware from supporting it is itself.

The code is there to allow for it. You will definitely get people who will come up with interpretations. I don't know if that's a valid reason to prevent me from using 1/2 the code that's been made here. :)

In case it's of any interest, here's the documentation: https://dev.clever.com/instant-login/bearer-tokens

[Tratcher]

Note that the missing state is only your first problem, next you'll hit the missing correlation cookie, and then you'll sign in but not know where to redirect to in the app. This provider really needs a custom middleware to handle their custom protocol.

[atrauzzi]

@Tratcher - The correlation cookie and other checks are exactly what I'm suggesting be backed off here.

You may not be understanding what I'm asking: If 1/2 the code you've got handles what I need, allowing for configuration of slightly different scenarios isn't unreasonable. Again, many frameworks that offer oauth support tend to acknowledge that there are variances.

[atrauzzi]

In lieu of trying to get this half-oauth2 approach working, I'm seeing if I can trick their half oauth2 process into triggering a regular one, but again I've come up against a hurdle:

If you look at their docs (https://dev.clever.com/instant-login/bearer-tokens#2-your-application-requests-an-access-token-from-clever-by-exchanging-the-code-), they say they want an Authorization header sent to the code exchange endpoint. This authorization header contains the client id and secret base64 encoded.

I was able to find one other place that suggests doing this: http://docs.apigee.com/api-services/content/oauth-20-client-credentials-grant-type -- not saying it's right or wrong.

HTTP client libraries offer a few methods to compute basic authentication. If your library supports setting a username and password, you'll want to set the username to your Client ID and the password to your Client Secret.

HTTP Basic auth headers are also easy to compute yourself. Start by constructing a string containing your Client ID followed by a colon (":") character and your Client Secret, then encode that string in Base64. Set your Authorization HTTP header to this encrypted string preceded by the keyword Basic and a space:

Obviously they preclude themselves from being targetable by standard libraries out of the box. But I have to say these kinds of things are not unusual for oauth server implementations out there.

So here's a second scenario where even when trying to do a regular oauth2 flow, I'm still missing a sufficient degree of control over things.

[Tratcher]

This was discussed recently: aspnet/Security#1032
Only a few providers support/require this, and there is extensibility in place to handle it. See https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers/blob/43e186945b9646652599dbf5988d0139850fbcfb/src/AspNet.Security.OAuth.Fitbit/FitbitAuthenticationHandler.cs#L61

[tmm360]

I've the same problem, I'm trying to login with FB from an app, FB redirects me to a state-less url with the code, and I can't create the state from the app.

[Tratcher]

@tmm360 do you have a link to the Facebook docs for the login flow your trying to use?

[tmm360]

I think to have solved my problem... I was following this guide https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/.
From my app I was redirecting the browser to https://www.facebook.com/v2.8/dialog/oauth?client_id={app-id}&redirect_uri={redirect-uri} with the client id of my service, and the redirect uri to an api endpoint of the service.
The problem was the missing of the state parameter handling the redirect call. Now, instead, I'm trying to call first an initialization action on my service from the app's browser, this will generate the state and redirect app to FB. Returning on service's page I will handle the call as a normal oauth authentication (it already works on web app), and on success I will reply a json instead of the user's home page (used on web app).

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.