Core.Portal.SignIn

Core.Portal.SignIn contains product-agnostic helpers for broker-backed portal sign-in.

The package calls the Core auth API through Core.Api.Clients.AuthApiClient, validates the returned JWT, optionally enforces transitional configured roles, and returns a cookie-ready ClaimsPrincipal. Product portals still own login pages, branding, antiforgery, redirects, cookie scheme names, SmartScheme routing, named authorization policies, permission vocabulary, and tenant-specific configuration.

Email-first portal flows use ICorePortalAuthDiscoveryService.DiscoverAsync(...) before asking for a password. The service calls POST /api/core/auth/discover with email, app/surface/principal context, and optional tenant hints. Core resolves a tenant from explicit hints, API-key context, a known identity user, or configured SSO email domains, then returns one of:

• redirect: start the returned NextProviderKey through /api/core/auth/start.
• choice: show the returned interactive providers.
• password: reveal the product-owned password form.
• needs_tenant_hint: use a direct tenant link or another tenant-safe hint; do not show a tenant picker by default.

Password recovery uses ICorePortalPasswordResetService. The default broker-backed implementation calls the canonical Core JSON auth endpoints:

• POST /api/core/auth/password/request-reset
• POST /api/core/auth/password/complete-reset

It carries configured tenant context plus optional per-request product code, reset URL base, and return URL. Product portals still own the Razor pages, validation text, reset email copy, and local proof-mode behavior. A portal that is not yet backed by Core identity may register its own ICorePortalPasswordResetService implementation while keeping the same page flow and result contract.

This package must not reference persistence, API controllers, workers, or product repos.

Example

builder.Services.AddCorePortalSignIn(builder.Configuration, options =>
{
    options.CoreApiBaseUrl = "https://api.example.com/";
    options.TenantApiKey = builder.Configuration["Portal:TenantApiKey"];
    options.ProductCode = "product-code";
    options.AppId = "product-portal";
    options.IncludeAccessTokenClaim = true;
    options.AuthorizationContextRefreshInterval = TimeSpan.FromMinutes(5);
    options.CookieAuthenticationScheme = "ProductPortal.Cookies";
});

The product login page or controller calls ICorePortalSignInService.TryCreatePrincipalAsync(...), then performs SignInAsync(...) with its own cookie scheme and redirect flow.

Product authorization uses the broker-issued permissions claim together with product/application context. Role names are administered bundles and should not be checked by product routes or navigation. RequiredRoles remains only as a migration compatibility check.

Portal cookie validation should call ICorePortalAuthorizationContextValidator.ValidateAsync(...) from the cookie scheme's OnValidatePrincipal event. Reject invalid results; replace and renew the cookie principal when WasRefreshed is true. The validator calls GET /api/core/auth/me, recomputes the current normalized role/permission context, and fails closed when the broker session is revoked, the user is inactive, the access token is missing, or refresh fails. IncludeAccessTokenClaim must therefore be enabled for broker-backed cookies that use this validator.

For shared signed-out UI, pair this package with Core.Portal.Chrome auth shell assets. The chrome package owns the Barlow typeface stack, html[data-theme] dark-mode behavior, and standard language selector/preference handoff; this sign-in package stays focused on broker-backed authentication.