6

https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1 states:

4.1.1. Authorization Request"

"state"

RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.

Is it safe to use a "state" parameter I generate (uuid/v4) in OAuth2 authorization request besides CSRF protection to identify the user in the provider callback in the authorization flow? Thus making the oauth2 flow "stateless" and don't require "sticky-sessions" for the load-balancer.

Currently, when a user starts the OAuth2 flow (visits login page) I create a unique auth-request-id and state for him and store it in Redis and send the auth-request-id in the cookies.

After the user logins into the provider (Google or Facebook) in the callback request, I try to find the user's session from the auth-request-id cookie in Redis and validate whether a session exists and that the received state matches the one I sent (against CSRF attacks).

Wondering, can I skip creating the auth-request-id cookie and identify the user in the callback by the state? Given the logic, if no matching state can be found in Redis, presume the state to be invalid and all Redis stored state has a 5 min expiry time.

Community
  • 1
Renārs Vilnis
  • 163
  • 3

1 Answers1

1

I believe You cannot do this securely.

Malicious actor can freely obtain redirects using your application. Now if he manage to make a unsuspecting victim to open redirect address then the victim will see that Your application is asking for access. If he grant access he will be redirected back to you, if you use only state to identify him then you just assigned victim resources to malicious actor account in your app.

AGrzes
  • 526
  • 4
  • 10