Intent.Blazor.Authentication

The Intent.Blazor.Authentication module provides a fully integrated authentication setup for Blazor applications generated with Intent Architect.
It supports all three Blazor rendering modes — InteractiveServer, InteractiveWebAssembly, and InteractiveAuto — and can be configured to work with multiple authentication strategies:

  • ASP.NET Core Identity
  • JWT Bearer Authentication
  • OIDC Password Flow

Rendering Mode Support

The appropriate services, AuthenticationStateProvider implementations, and dependency injection (DI) registrations are generated according to the selected rendering mode to ensure a seamless authentication flow.

Each rendering mode uses a tailored implementation of the AuthenticationStateProvider to match its runtime environment.
By default, authentication state is persisted using cookies in all modes, unless overridden.

Supported Authentication Modes

You can configure this module to support:

  • ASP.NET Core Identity – For individual accounts using a local store. This mode sets up an Entity Framework Core database to store user data and account information. It includes built-in functionality for user registration, login, password reset, and email confirmation. Note: This mode does not support attaching a token to a third-party API.

  • JWT (JSON Web Token) – For stateless authentication using tokens. A TokenEndpoint:Uri must be configured in your app settings. The module handles typical user flows including login, registration, password reset, and forgot password — assuming your token provider supports these endpoints.

  • OIDC Password Flow – For integration with third-party identity providers like IdentityServer, Auth0, or Azure AD B2C. This mode supports the Resource Owner Password Credentials (ROPC) grant flow, allowing users to authenticate using their username and password directly against the identity provider.

In all three modes, the authenticated ClaimsPrincipal is stored in either the IdentityCookie or a general Cookie, depending on the configuration.

Account Pages

The Login, Register, ForgotPassword, ResetPassword, ConfirmEmail and ResendEmailConfirmation account pages are modelled Component/Page elements — the "Security Type" stereotype's page-tagging automatically models one for each page that applies to your selected Authentication mode. They are generated by the same generic Razor component template used for any other modelled page, so:

  • The first time a page is generated, it is seeded with this module's default markup and code-behind.
  • On every later generation, your edits to the page are preserved — only the page's route/title directives refresh from the model.
  • If you delete a page's modelled element, it stops being generated.

AccountLayout (the shared layout shell for these pages) is still a plain, always-regenerated template and is not modelled.

Third-Party API Authentication

Authentication for secure third-party APIs can be achieved using either JWT or OIDC modes.

In these modes, the access token (auth_token) retrieved from the configured token provider is automatically attached to any outgoing HTTP requests targeting Secured API endpoints.
This ensures that all protected resources are accessed with the appropriate authorization headers without requiring manual token handling.

Configuration

OIDC Password Flow

An OIDC application generates placeholders for the keys it reads into the server project's appsettings.json. Both must be filled in before the application can log in:

{
  "TokenEndpoint": {
    "Uri": "https://localhost:44391/identity/"
  },
  "Authentication": {
    "OIDC": {
      "ClientId": "",
      "ClientSecret": "",
      "DefaultScopes": "openid profile api"
    }
  }
}
Key Consumed by
TokenEndpoint:Uri Base address of the "oidcClient" HttpClient registered in Program.cs
Authentication:OIDC:* Bound to OidcAuthenticationOptions; OidcAuthService.Login throws if any of the three is blank
  • TokenEndpoint:Uri requires a trailing slash. It is a base address resolved against the relative path connect/token, so a value without the trailing slash loses its sub-path — for example https://host/identity resolves to https://host/connect/token.
  • ClientSecret belongs in user-secrets or environment variables, not in the committed file.
  • A refresh token is only issued when offline_access is in DefaultScopes and the identity provider's client has offline access enabled (AllowOfflineAccess = true on IdentityServer). Its absence is a supported configuration — the generated code tolerates a token response with no refresh_token.
  • No environment-specific override file is generated. These keys need production values supplied through your own appsettings.Production.json, environment variables, or secret store.

Token refresh

Browser-side token refresh is generated for the JWT mode only, where refresh is a genuine ASP.NET Core Identity endpoint.

OIDC ships without it: an OIDC provider expects a form-encoded grant_type=refresh_token at connect/token, which would require a client_id in the browser, a public client registration and browser-origin CORS — giving away the property that makes the server-side OIDC design preferable. An OIDC application therefore routes the user back to the login page when the access token expires, and no refresh token is sent to the browser.