Chapter 8: Application security in Aspire
The chapter introduction explains why publicly accessible Aspire applications need security, why the approach is not tied to one identity provider, and why the dashboard needs separate protection.
After this chapter you will be able to
- Security for public applications. Explain why a publicly accessible, nontrivial application orchestrated by Aspire should restrict access to authorized users.
- Single sign-on and identity providers. Explain how single sign-on lets a user authenticate across applications protected by the same identity provider.
- Login redirect and token lifecycle. Trace the simplified SSO flow from an unauthenticated request through the IdP login, return to the requested page, and continued access using a token.
- OIDC address requirements. Explain which publicly accessible addresses an application and its identity provider need for OIDC sign-in, and why redirecting applications must be registered with the IdP.
- Frontend redirect URL resolution. Trace how the local Aspire host obtains the frontend’s standard URL and passes it to Keycloak for the postlogin redirect.
- IdP discovery backchannel. Explain how the UI and API can use Aspire service discovery to contact a co-hosted IdP without treating its discovery URI as an authentication authority URL.
- Cookie and OIDC scheme roles. Distinguish the cookie authentication scheme from the OIDC challenge scheme in the UI application.
- Protected order-tracking page. Trace how authorization registration, middleware, and a Razor page attribute restrict access to the order-tracking page.
- Authentication-dependent order controls. Explain how AuthorizeView changes the product and order controls shown to signed-in and unsigned-in users.
- Blazor sign-in connection. Describe the frontend setup that lets AuthorizeView use authentication state and sends users through sign-in and back to ordering.
- API JWT authentication. Explain why the UI-less API expects an already-authenticated client to send a valid JWT in the HTTP request header, rather than redirecting the caller to an identity-provider login page.
- Authority and audience settings. Describe the Authority setting's role in checking a received token, and explain why this example does not validate its audience while a gateway or microservice may need to.
- Order endpoint authorization. Describe the authorization setup and how RequireAuthorization() protects the order placement endpoint.
- Bearer token in API requests. Trace how ProductsApiClient passes a logged-in user’s access token to the API: it receives authentication state, extracts the token in MakeOrder(), and puts it in the request’s authorization header as a Bearer token.
- Dashboard authentication configuration. Describe where the Aspire host configures dashboard authentication and how AuthMode selects a mechanism, including the restriction on using Unsecured.
- Default browser token access. Explain what the default BrowserToken mode requires when the host is started with dotnet run and where to find the token.
What it builds on
- Adding a Keycloak container to an Aspire host (chapter 2) · The earlier example of adding a Keycloak container to an Aspire host.
- Service discovery in Aspire (chapter 1) · Aspire service discovery and service references.
Section by section
Introduction
The chapter introduction explains why publicly accessible Aspire applications need security, why the approach is not tied to one identity provider, and why the dashboard needs separate protection.
- Security for public applications: Explain why a publicly accessible, nontrivial application orchestrated by Aspire should restrict access to authorized users.
Why it matters: Aspire orchestration does not remove the need to protect a public application. - Identity provider independence: Explain why the chapter’s security approach can apply with either an external identity provider or a self-hosted Keycloak container.
Why it matters: The security approach is not limited to the Keycloak setup used earlier in the book. - Separate dashboard protection: Explain why the Aspire dashboard should be secured separately from the application.
Why it matters: Protecting the application alone does not address access to its management dashboard and internal logs.
Key terms: authorized users, Aspire, orchestrated application, authentication provider, authentication and authorization protocols, fixed endpoint, Keycloak, Aspire dashboard, internal logs, separate mechanism
8.1 A brief introduction to single sign-on
Introduces single sign-on, its identity-provider and token flow, and why authentication matters for the online shop.
- Single sign-on and identity providers: Explain how single sign-on lets a user authenticate across applications protected by the same identity provider.
Why it matters: This is the shared-login idea behind the chapter’s security example. - Login redirect and token lifecycle: Trace the simplified SSO flow from an unauthenticated request through the IdP login, return to the requested page, and continued access using a token.
Why it matters: The redirect and token explain how a successful login continues to count on later requests. - Authentication versus authorization protocols: Distinguish OIDC’s authentication role from OAuth’s authorization role in the section’s high-level account of SSO.
Why it matters: It separates proving identity from deciding which resources that identity may access. - Online shop authentication rationale: Justify why online-shop users need registered, protected accounts before placing orders.
Why it matters: It connects SSO to concrete risks in the shop rather than treating login as an isolated feature.
Key terms: single sign-on (SSO), identity provider (IdP), IdP, token, redirect, browser cookie, OpenID Connect (OIDC), OAuth, authentication, authorization
8.2 Using service discovery in SSO
This section explains how Aspire supplies the addresses needed for OIDC single sign-on, including local redirect URLs and service-discovered communication with the identity provider.
- OIDC address requirements: Explain which publicly accessible addresses an application and its identity provider need for OIDC sign-in, and why redirecting applications must be registered with the IdP.
Why it matters: These addresses let the application reach the IdP and let the IdP redirect the user back to the right application. - Frontend redirect URL resolution: Trace how the local Aspire host obtains the frontend’s standard URL and passes it to Keycloak for the postlogin redirect.
Why it matters: Passing the resolved URL gives the local Keycloak realm the frontend’s actual postlogin destination. - Local and production address handling: Distinguish why automatic endpoint resolution is limited to local development and how IdP addresses are handled on a real host.
Why it matters: The local shortcut must not be mistaken for a production address or security strategy. - IdP discovery backchannel: Explain how the UI and API can use Aspire service discovery to contact a co-hosted IdP without treating its discovery URI as an authentication authority URL.
Why it matters: It separates Aspire’s internal way of locating a service from the standard URL expected in authentication settings.
Key terms: SSO, OIDC, IdP, redirect address, HTTPS endpoint, HTTP endpoint, WEBAPP_HTTP_CONTAINERHOST, Keycloak container realm import, local development environment, unsecured HTTP endpoint
8.3 Enforcing UI authentication
This section explains how the OnlineShop.Web UI configures cookie and OIDC authentication and restricts an order-tracking page to authenticated users.
- Cookie and OIDC scheme roles: Distinguish the cookie authentication scheme from the OIDC challenge scheme in the UI application.
Why it matters: The UI needs both a way to recognize a signed-in user and a way to send an unsigned-in user to sign in. - OIDC provider connection settings: Describe how the UI identifies and communicates with its OIDC identity provider.
Why it matters: These settings connect the UI's sign-in challenge to the intended identity provider and identify the application to it. - OIDC flow and token options: Explain what the configured response type and token-saving option do, and state the development-only caveat for non-HTTPS metadata.
Why it matters: These options affect how the UI obtains and retains tokens and whether its metadata setting is suitable outside development. - Protected order-tracking page: Trace how authorization registration, middleware, and a Razor page attribute restrict access to the order-tracking page.
Why it matters: The page restriction works through the configured authentication pipeline rather than a hand-written login redirect.
Key terms: AddAuthentication(), DefaultScheme, DefaultChallengeScheme, AddCookie(), AddOpenIdConnect(), Backchannel, Authority, ClientId, ClientSecret, IdP
8.3.1 Partially enforcing security
This section makes order controls conditional on authentication, connects the Blazor frontend to sign-in, and identifies the limit of frontend-only protection.
- Authentication-dependent order controls: Explain how AuthorizeView changes the product and order controls shown to signed-in and unsigned-in users.
Why it matters: The reader can explain why an unsigned-in shopper sees a sign-in prompt instead of order controls. - Blazor sign-in connection: Describe the frontend setup that lets AuthorizeView use authentication state and sends users through sign-in and back to ordering.
Why it matters: This connects the conditional UI to a working sign-in experience rather than just hiding buttons. - Frontend security boundary: Distinguish the frontend protection implemented here from protection of the API endpoint.
Why it matters: It prevents the reader from mistaking hidden UI controls for protection of the underlying API.
Key terms: AuthorizeView, Authorized, NotAuthorized, Sign in to order, CascadingAuthenticationState, Routes.razor, sign-in and sign-out endpoints, SSO middleware, IdP, frontend
8.4 Enforcing API authentication
This section explains how OnlineShop.ApiService validates JWTs on incoming requests and requires authorization for its order placement endpoint.
- API JWT authentication: Explain why the UI-less API expects an already-authenticated client to send a valid JWT in the HTTP request header, rather than redirecting the caller to an identity-provider login page.
Why it matters: An API without a user interface needs the caller to provide a token rather than relying on an interactive login flow. - Authority and audience settings: Describe the Authority setting's role in checking a received token, and explain why this example does not validate its audience while a gateway or microservice may need to.
Why it matters: Token validity and whether a token was intended for a particular API are distinct checks. - Order endpoint authorization: Describe the authorization setup and how RequireAuthorization() protects the order placement endpoint.
Why it matters: Configuring token authentication is not the same as requiring it on the order placement endpoint.
Key terms: OnlineShop.ApiService, JSON Web Token (JWT), authentication scheme, Authority, IdP, ValidateAudience, TokenValidationParameters, Audience (aud), authorization components, authentication and authorization middleware
8.4.1 Passing a JWT to the API
This subsection shows how the web UI forwards a logged-in user’s access token to the backend API as a bearer token.
- Bearer token in API requests: Trace how ProductsApiClient passes a logged-in user’s access token to the API: it receives authentication state, extracts the token in MakeOrder(), and puts it in the request’s authorization header as a Bearer token.
Why it matters: Forwarding the token connects the user’s UI login to the request made to the backend API.
Key terms: ProductsApiClient, authentication state, access token, authorization header, Bearer
8.5 Securing the Aspire dashboard
This section explains how to choose an authentication mode for the Aspire dashboard and how its default browser-token access works.
- Dashboard authentication configuration: Describe where the Aspire host configures dashboard authentication and how AuthMode selects a mechanism, including the restriction on using Unsecured.
Why it matters: Dashboard access needs its own security configuration, separate from securing the applications Aspire hosts. - Default browser token access: Explain what the default BrowserToken mode requires when the host is started with dotnet run and where to find the token.
Why it matters: This explains the authentication prompt a reader may encounter when opening a locally run dashboard. - External OIDC provider: Justify using an identity provider hosted outside Aspire when selecting OpenIdConnect for dashboard authentication.
Why it matters: An Aspire-hosted identity provider could leave the dashboard inaccessible when that provider is down.
Key terms: Dashboard, Frontend, AuthMode, appsettings.json, Unsecured, BrowserToken, dotnet run, access token, OpenIdConnect, OIDC
8.6 Summary
Where this is used later
- Predeployment modifications of Aspire-hosted systems (chapter 9) · Production preparation must account for addresses that cannot be resolved by this local-development code.
Concepts explained in this chapter
- authenticationAuthentication is the process of verifying the identity of a user or other principal.
- authorizationAuthorization is the process of determining which actions or resources an authenticated principal is permitted to access.
- openid connectOpenID Connect is an identity layer built on OAuth 2.0 that enables clients to verify user identity and obtain basic profile information.
- Razor attributeA Razor attribute is metadata attached to a Razor component or page that influences its framework-defined behavior.
- authentication schemeAn authentication scheme defines how an application reads and validates the current authenticated identity.
- challenge schemeA challenge scheme determines the authentication action taken when an unauthenticated user requests a protected resource.
- OAuthOAuth is an authorization framework that enables clients to obtain limited access to protected resources without handling the resource owner's credentials.
- identity providerAn identity provider is a system that authenticates principals and supplies identity information and access-related assertions to applications.
- single sign-onSingle sign-on is an authentication mechanism that lets a user access multiple applications after authenticating once.
- service discoveryService discovery is a mechanism by which services locate the network endpoints of other services dynamically rather than relying on fixed addresses.
- Proof Key for Code ExchangeProof Key for Code Exchange is an OAuth security extension that binds an authorization-code exchange to the client that initiated it.
- authorization code flowThe authorization code flow is an OAuth-based protocol in which a client exchanges an authorization code for tokens through a server-side interaction.
- Aspire dashboardThe web interface that presents the state and telemetry of resources in an Aspire application.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.