IdentityServer4 — Part 1

OAuth 2.0 is an open standard authorization protocol developed by the IETF OAuth Working Group. It defines standardised methods to securely authorize web, mobile, and desktop applications without specifying an implementation.

OpenID Connect is a thin layer on top of OAuth 2.0 that adds user authentication. It introduces the id_token — a signed JWT containing user identity claims — on top of the access token mechanism.

IdentityServer is an open-source .NET framework that implements these protocols, providing built-in support for all OAuth 2.0 flows.

Client Types

Clients are classified by their ability to keep a secret:

• Confidential clients — can maintain credential secrecy. They run on the server and can safely store a client_secret.
• Public clients — cannot maintain credential secrecy. They run in browsers or on devices where secrets cannot be safely stored.

Channels

Flows use two channels with different security levels:

• Front channel — the browser. Less secure; used for redirects and authorization codes that are short-lived.
• Back channel — the server. Highly secure; used for exchanging secrets and tokens.

OAuth 2.0 Flows

1. Authorization Code — front channel obtains an authorization code; back channel exchanges it (with the client secret) for the access token.
2. Implicit — front channel only; access token is returned directly from the authorization endpoint. No client secret involved.
3. Resource Owner Password Credentials — back channel only. User credentials are sent directly to the token endpoint. Legacy; use only for compatibility with older applications.
4. Client Credentials — back channel only. Machine-to-machine authorization; no user context. The client accesses resources using its own client_id and client_secret.

OpenID Connect Flows

OpenID Connect adds the id_token scope to alter existing flows and defines a new one:

1. Authorization Code Flow — returns an authorization code, exchanged via back channel for both an access token and an identity token.
2. Implicit Flow — tokens issued directly without client authentication. Refresh tokens are not allowed.
3. Hybrid Flow — combines the previous two. The client can immediately use an id_token from the front channel while exchanging the auth code for an access token in the back channel.

Flows can also be grouped by the number of steps:

• 2-Legged — client_credentials, resource owner password, implicit
• 3-Legged — authorization_code (requires the extra redirect step)

response_type vs grant_type

These two parameters target different endpoints:

• response_type targets the authorization endpoint. It tells the server what the client expects back (a code, a token, or an id_token) and which flow will be triggered.
• grant_type targets the token endpoint. It tells the server what the client is exchanging for an access token — an authorization code, a refresh token, or client credentials.