Difference between OAuth 2.0 "state" and OpenID "nonce" parameter? Why state could not be reused?

Question

OAuth 2.0 defines "state" parameter to be sent in request by client to prevent cross-site request attacks. Same is mentioned in OpenID spec for "nonce". Apart from the fact that "nonce" is returned in ID token instead of query parameters, they appear to serve the exact same purpose. If someone can explain why they are separate

Answer 1

Nonce

This is a "number, used once" that is included in your token. Because it changes every time, it's specifically designed to prevent replay attacks. This prevents previously valid responses from being reused.

State

State is a string sent as a request to the server, which the server sends back in its response. This prevents Cross-Site Request Forgery (CSRF) attacks, ensuring responses aren't sent from malicious third parties.

Answer 2

This is my understanding of State vs Nonce. I am not sure if it is 100% accurate, so let me know if anything needs adjustment. Hopefully this helps.

State

• OAuth 2.0: HTTP CSRF Token only
• OIDC 1.0: HTTP CSRF Token, and session ID to lookup Nonce for comparing to ID Token nonce claim

Nonce

• OAuth 2.0: Not part of the specification because opaque tokens (i.e. no JWTs => no Nonce claims)
• OIDC 1.0: ID Token claim

State (OAuth 2.0)

User Agent calls Authz Client twice in OAuth 2.0 Authz Code Grant Flow. For example:

1. Start flow: http://authzclient/start
2. Finish flow: http://authzclient/finish?state=AUTHZ_CLIENT_CSRF&code=AUTHZ_SERVER_CODE

Response 1 points to Authz Server, with redirect_uri and State to point User Agent back to Authz Client.

http://authzserver/authorize?redirect_uri=http://authzclient/finish?client_id=client1&state=AUTHZ_CLIENT_CSRF&response_type=code&scope=SCOPE1%20SCOPE2

Notice there is no openid scope and no nonce parameter. This example is OAuth 2.0 only, not OIDC 1.0.

As a CSRF Token, it doesn't matter if many Authz Server calls happened between the two Authz Client calls. State is still valid as a CSRF Token for the second request to the Authz Client (e.g. a Web Server).

State (OIDC 1.0)

State is used as an ephemeral CSRF Token just like in OAuth 2.0. However, it seems OIDC 1.0 reuses it as a long term Authz session ID too. For example, State is used to validate a Nonce claim in an ID Token.

Nonce is not part of OAuth 2.0. The original OAuth 2.0 said to use opaque Access Token and Refresh Token (i.e. not JWTs). When Nonce was added, I think that is where State was given a second purpose.

Nonce (OIDC 1.0)

Adding an openid scope and Nonce parameter to the previous example response makes it OIDC 1.0 now.

http://authzserver/authorize?redirect_uri=http://authzclient/finish?client_id=client1&state=AUTHZ_CLIENT_CSRF&response_type=code&scope=openid%20SCOPE1%20SCOPE2&nonce=CLIENT_NONCE_CLAIM

The Authz Client:

• receives Authz Code and State query parameters from User Agent
• verifies if State matches any existing (i.e. unfinished) flow
• receives ID Token (with Nonce claim) from Authz Server
• uses State query parameter as a session ID, to lookup Nonce value generated at same time as State
• verifies Nonce from the session matches the nonce claim in the ID Token

During the flow, the State is used to do a lookup of the original Nonce for validating the ID Token.

After the flow, the ID Token nonce claim can be used to do a reverse lookup to get the original State. That points to the original Authz Session, which may contain extra information not in the ID Token.

Answer 3

Nonce

The nonce gets baked into the ID token, which is a signed JWT. This guarantees that the ID token you receive is the same ID token that you requested.

Such a mechanism may seem unnecessary at first, but remember that in most cases you're using identity providers like Google which will issue ID tokens to just about anyone for any reason. So an attacker can trick your app's legitimate user into logging into an unrelated app using their Google account, then pass that token off to your app which, if not using nonce validation, will accept the token and allow the attacker to masquerade as the legitimate user for whom the token was issued.

A less secure but still better-than-nothing way to protect against this kind of attack would be to check the aud (audience) claim of the ID token, which is probably how this was intended to work before OIDC nailed down the more-secure nonce mechanism. However, such a check is not immune to replay attacks, where the same token is presented more than once.

State

The state comes back to you as a parameter in the request to your authentication callback. This guarantees that the invocation of your callback is the end result of the authentication flow that you kicked off.

Again, such a mechanism may seem unnecessary at first, but remember that anyone from anywhere on the web can invoke your callback. Even if most of the security logic lives in a backend server, an unexpected invocation of your callback can still corrupt client-side state leaving the end user unable to get things done in your app. Your app can also be turned into a confused deputy sending useless or even malicious requests to the server, which may lead to denial of service or other issues.

You might think to use the Referer header for this purpose, but that is fraught with peril. There are lots of ways to manipulate that header, OIDC providers don't have to document where their redirects come from, and you're going to have to do full URL parsing to extract the important parts. Whereas proper use of the state parameter can reduce secure operation to a simple equality check.

Both

Both the nonce and state values should be:

1. opaque: an attacker can't glean other sensitive information from them,
2. unforgeable: an attacker can't construct a legitimate value deterministically, and
3. unguessable: an attacker can't brute-force the value in a short amount of time.

Generally, generating values with a cryptographically secure pseudo-random number generator that have at least 96 bits (12 bytes) of entropy should meet these demands today.

Also, these values are designed to protect against common, low-to-medium-effort attacks on the public Internet. A highly resourced attacker who can hijack your infrastructure or perform TLS man-in-the-middle attacks against your app won't be stopped by these mechanisms.

Answer 4

To demonstrate the difference, let's consider a situation where state exists but nonce doesn't and the attacker is able to intercept the authentication response (redirection from the Authorization Server or OIDC Provider to the client) and inject a malicious authorization code with the same state parameter. This is more likely to happen for native applications and can be mitigated by using nonce parameter approach.

OR the attacker can easily use the intercepted authorization code on the attacker's client application to log in to the victim's account. (This can also happen if nonce exists because the attacker can alter the client application to bypass nonce checking. This should be prevented by the authorization server or OIDC Provider by detecting multiple usages of the same authorization code or giving exact same consent in a short time)

PKCE can also be used as a sophisticated method, but all of the authorization servers or OIDC Providers may not support it.

Answer 5

Actually "NONCE" is enough to validate sender and response. But before you should open the token to read "NONCE". beacuse of this you have to accept response if there are millions fake respose you will accept all of those to open token and read "NONCE". But state is allready opened on response header, you can easly read state and easly reject fake response. this is two level ceheck.

Answer 6

As a MiiT actor, Mallory intercepts the ID token somehow and relays the token to Relying Party (aka protected service, resource server). Relying Party denies the ID token because no session cookie in Mallory's browser. The simplified relation between nonce and session, nonce = hash(session, seed_rotated_regularly)

State is a CSRF token generated by relying party in every HTTP response. As a user, Alice clicks a phishing link accidentally and her user agent is redirected to the authentication service (aka OP, IdP). Thanks to single sign-on, Alice does not notice the HTTP 302 back and forth. Assume the phishing website is allowed in redirect_uri. Relying Party can deny the HTTP request with a valid token obtain by the phishing website because state is not presented. Nonce does not work in this case because session cookie is in Alice's user agent. State cannot prevent MiiT because Mallory can get the token, state, but not the session cookie.

Answer 7

Adding to the above answers which focus on the security aspect of state and nonce, if you're implementing your own 3-legged OAuth2 workflow (client, your middleware and a Federated Identity Provider such as Facebook), your middleware might sometimes need some context. For example, when the response from the FIP reaches back to your middleware before going back to your client, you may need to know more about the details of the original request (i.e., the original request to the FIP). Because your middleware is most likely stateless, it won't be able to answer that question without any help. That's where the OAuth2 state variable comes in. You could store any string that represents the state you want to pass between all the OAuth2 jumps so that your middleware (as well as your client) can use some more context. In the case of your client, this is used for security reason. The nonce is used as part of the OIDC specification for pure security reasons.

Answer 8

I am stating an explanation from their RFCs. The explanation is pretty straightforward.

State

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

Nonce

The nonce parameter value needs to include per-session state and be unguessable to attackers. One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter. In that case, the nonce in the returned ID Token is compared to the hash of the session cookie to detect ID Token replay by third parties. A related method applicable to JavaScript Clients is to store the cryptographically random value in HTML5 local storage and use a cryptographic hash of this value.

Reference Link: State: https://datatracker.ietf.org/doc/html/rfc6749

Nonce:https://openid.net/specs/openid-connect-core-1_0-17_orig.html

Hope this answers your question.

Answer 9

State and nonce seem to be similar. But if you dig deep, you will find that they serve different purposes.

State is there to protect the end user from cross site request forgery(CSRF) attacks. It is introduced from OAuth 2.0 protocol RFC6749. Protocol states that,

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

And this is used in authorization request. It enables the client to validate that the authorization response is not altered and sent by the original server which auth. request was sent. In short, it allows the client to cross check the authorization request and response.

(More elaboration : To accept authorization code response, client need to accept a response from authorization server (ex:- In web app, this can be done by a redirect and a form post to back-end). This means, our client application have an endpoint which is open and accept requests. State parameter protect this endpoint by binding original authorization requests to responses. This is CSRF protection.)

Nonce serves a different purpose. It binds the tokens with the client. It serves as a token validation parameter and is introduced from OpenID Connect specification.

nonce - String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used. The nonce value is a case sensitive string

As you can see, nonce value originates from the authorization request and it is generated by the client. And if nonce is included, it will be present in the token. So the client can validate the token it received against the initial authorization request, thus ensuring the validity of the token.

Also, depending on the flow type, nonce can be a mandatory parameter. The implicit flow and hybrid flow mandate nonce value. Both values are generated and validated by client application.

Why state could not be reused?

If an authorization request is captured, then the malicious party can fake the authorization response. This can be avoided by altering state parameter.

Answer 10

Nonce answers the question to the browser: Is this ID token a response to my initial request?

State answers to the backend server: did the consent really come from who I think it did?

So they answer similar questions but to different entities.