OpenID Connect (OIDC) handles authentication: proving that a user is who they claim to be. In single sign-on (SSO), a shared identity provider (IdP) lets a user sign in once and access applications protected by that provider. OAuth addresses the separate question of authorization: whether the user may access a resource. section 8.1 section 8.6
For an online shop, signing in establishes who placed an order and helps prevent someone else from using a customer’s account. Keycloak acts as the IdP; the web application redirects unauthenticated users to it when they request protected pages. section 8.1 section 8.3
builder.Services.AddAuthentication(options =>
{
options.DefaultScheme =
CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme =
OpenIdConnectDefaults.AuthenticationScheme;
})
.AddCookie(
CookieAuthenticationDefaults.AuthenticationScheme)
.AddOpenIdConnect()
.ConfigureWebAppOpenIdConnect();
The UI registers cookie authentication as its default scheme and OIDC as its default challenge scheme. The cookie scheme reads the current identity; the OIDC challenge redirects an unauthenticated user to sign in. section 8.3
To enforce authentication in an ASP.NET Core UI:
- Add Microsoft.AspNetCore.Authentication.OpenIdConnect and configure the IdP authority URL and backchannel HTTP client. section 8.3
- Register authorization and place authentication and authorization middleware in the request pipeline. section 8.3
- Mark pages requiring sign-in with the Authorize attribute. section 8.3
The signed-in state is retained temporarily, such as in a browser cookie. Access tokens expire and can be refreshed while the user remains active; eventually, the user must sign in again. This is the operational reason to configure both the sign-in challenge and the mechanism that reads an existing identity. section 8.1 section 8.3
