Oauth2 state persistency

[#1]

Hi all,

as per OAuth2 spec (Code Grant flow) the state parameter should be maintained on the OAuth server side: "the authorization server includes this value when redirecting the user-agent back to the client.".

Does this mean that Edge has to persist/cache the state param during the token generation phase? If yes, what is the recommended practice?

thanks lot,

Antonio

[adas]

No, this need not be persisted on the OAuth server side. As long as the client includes a "state" parameter in the request and is able to verify that it was sent back in the response, that's all that matters. We do not persist the state in Edge.

The “state” parameter is intended to preserve some state object set by the client in the Authorization request, and make it available to the client in the response.  The main security reason for this is to stop Cross Site Request Forgery (XRSF).
XRSF attacks are not new or specific to OAuth.   The way to prevent them in OAuth is to include something in the request that the client can verify in the response but that an attacker could not know.  An example of this would be a hash of the session cookie or a random value stored in the server linked to the session.   If the OAuth client verifies the value returned than it will reject authentication responses that were generated as the result of requests by third party attackers trying to log the user in in the background without the users knowledge.


The “state” parameter is just a string so any other information can be encoded in it.

Disclaimer: This is not Edge or Apigee specific.

[#3]

thanks Arghya.

To me the confusion still persists. Reference to OAuth2 spec. : https://tools.ietf.org/html/rfc6749#section-10.12

   Once authorization has been obtained from the end-user, the
   authorization server redirects the end-user's user-agent back to the
   client with the required binding value contained in the "state"
   parameter.  The binding value enables the client to verify the
   validity of the request by matching the binding value to the
   user-agent's authenticated state. 

Ok, maybe it is open to interpretation. Who stores the state? I understand that a practice is that the "state" can also be persisted by the login app.

Antonio

[ozanseymen · Accepted solution]

Hi @antonio bruno

I guess the question is which component is storing the session state through the authentication steps for your implementation?

E.g. if you have a separate login application that handles user credentials input and consent, that app is already storing some kind of a session state, therefore should also store the state query parameter value.

If you are using Apigee to implement the login pages, e.g. using node.js, then session state will be stored within Apigee, therefore OAuth state value can also be part of that.

If you store OAuth state value in Apigee but not in your server-side login app, then you have two application states that need to be in sync. Obviously this is a problem so you will want to store the session in one place which will need to be where the login app lives.

[#5]

Thanks Ozan. Infact we plan to store the state in the login app. Mine was just a question to understand the practices of such design. But you answered.

thanks again,

Antonio