OpenID Connect <debugger/>

Test OpenID Connect requests and debug responses.

Crafted by Nate Barbettini

The authorize URI on the authorization server is where an OpenID Connect flow starts.

The redirect URI tells the issuer where to redirect the browser back to when the flow is done.

Every client (website or mobile app) is identified by a client ID. Unlike a client secret, the client ID is a public value that does not have to be protected.

Clients can request additional information or permissions via scopes. The openid scope is the only required scope.

The OpenID Connect spec defines some standard scopes, and applications can define their own custom scopes as well.

The state is an optional value that is carried through the whole flow and returned to the client.

It's common to use state to store an anti-forgery token that can be verified after the login flow is complete. Another common use is storing the location the user should be redirected to after logging in.

A nonce (or number used once) is a random value that is used to prevent replay attacks.

The authorization server will respond with a code, which the client can exchange for tokens on a secure channel. This flow should be used when the application code runs on a secure server (common for MVC and server-rendered pages apps).

The authorization server will return an access and/or ID token directly back to the client. This flow is not as secure as the Authorization Code flow, but supports JavaScript single-page applications that need to directly receive tokens.

The authorization server will respond with both a code (which the client can exchange for tokens on a secure channel) and an ID token. A common use case for the hybrid flow is using the code to get an access token on the server, and directly consuming an ID token on the client.