CODEWITHSUNDEEP
openid-connect
Johannes Jasper
Johannes Jasper

Reputation: 921

Purpose of state and nonce in OpenID Connect Code flow

I am trying to figure out what state and nonce are good for in the OpenID Connect code flow.

From what I read so far, the main attack seems to be that an attacker could intercept the authentication response, including the authorization code. If the attacker replayed the authentication response, however, the auth code would already be used and the OP would reject the token request. I saw, that the spec does not require the auth code to be a one time password, in that case I see how a replay would be possible. We, however, invalidate the auth code after use.

I also understand that, using CSRF, an attacker could call my clients redirect-uri, using a different auth code. I yet don't see how that code would be valid at the OP. Is the idea that the attacker could guess a valid auth code?

Can anybody show me an attack vector, that is solved with state and/or nonce?

Upvotes: 15

Views: 15540

Answers (1)

Kavindu Dodanduwa
Kavindu Dodanduwa

Reputation: 13059

OpenID Connect inherits the state parameter from OAuth 2.0. The nonce parameter comes with the OpenID Connect spec. They have two different purposes. Here is a link to an SO answer which explains them.

In an authorisation flow, you have two steps. First you receive an auth code and then you use the auth code to obtain access tokens. When you receive a response at the redirect URL, there must be a way to verify that the response came for a request which you sent. The state value solves this issue by binding request and response. It is the client which should validate the response.

An authorisation code is short lived (30 to 120 seconds) and I do not believe it can be the same for many requests. Usually the code must be a one-time password.

nonce connects tokens to original client requests. If nonce is present in the authorisation code request, it must be present in the id token received from a successful OpenID Connect flow. This way, the client knows the token is generated for itself and it won't consume a token injected by some malicious party.

Upvotes: 14

Related Questions