Where should the 'state' nonce be generated and checked?

Help
,
1

My application consists of a client side html/javascript, a web server, and an API (a “regular web app”, as auth0 calls it). On the Authorization Code Grant doc page, it says to create a URL like this the user can follow:

https://ygctest.auth0.com/authorize? 
    audience=YOUR_API_AUDIENCE&
    scope=YOUR_SCOPE&
    response_type=code&
    client_id=YOUR_CLIENT_ID&
    redirect_uri=https://YOUR_APP/callback&
    state=YOUR_OPAQUE_VALUE

The doc says the statereturned from the auth0 server via query parameter to /callback needs to be compared to the originally generated state.

My question is: Where should the “state” variable be generated? And, does the state variable need to be verified on the client, server, or both?

Should I generate it on the server and pass it to the client somehow? If so, is it better to do it as a cookie, or can I just generate the entire URL serverside and stick it in the html?

If the state variable should be generated on the client side, how should the server know what the client thinks the state is? The browser is redirected from the login page to /callback (in the example), so the client doesn’t have a chance to check the state. Should the client set a cookie so that the GET to /callback includes the state?

I also noticed that the Flask Example doesn’t mention a state variable at all. Does it not do state checking, or does it do it behind the scenes?

2

Hi @tnish,

state and nonce are two different things, one used by clients to restore the state of the app previous to the authorization request, and nonce to prevent replay attacks with the id_token.
More info on nonce: Final: OpenID Connect Core 1.0 incorporating errata set 1
draft-ietf-oauth-v2-threatmodel-06

They can be generated on the client or on the server, depending on the type of application. Auth0.js (and Lock) for example generates them both if the request doesn’t provide them.

state should also be used to prevent Cross-Site Request Forgery attacks. draft-ietf-oauth-v2-threatmodel-06

Just putting some light on the subject, can you please let me know if that clarifies things a bit?