Vefa.CustomAuth.AspNetCore
Package details for Vefa.CustomAuth.AspNetCore.
Details
- group
- Vefa.CustomAuth
- version
- 3.0.0
- slug
- vefacustomauthaspnetcore
Links
Vefa.CustomAuth.AspNetCore
ASP.NET Core endpoint and dependency injection integration for Vefa.CustomAuth.
This package maps OAuth2 and OpenID Connect endpoints and registers the runtime services used by the authorization server.
Typical Usage
builder.Services
.AddCustomAuth(options =>
{
options.Issuer = "https://auth.example.com";
})
.AddJwtTokenSigning();
app.MapCustomAuthEndpoints();Register a persistence provider separately, such as `Vefa.CustomAuth.EntityFrameworkCore` or `Vefa.CustomAuth.MongoDB`.
Endpoints
GET /.well-known/openid-configuration
GET /.well-known/jwks.json
GET /connect/authorize
POST /connect/token
GET /connect/logout
POST /connect/logout
GET /connect/userinfo
POST /connect/userinfo
POST /connect/revoke
POST /loginThis package ships no HTML. The host application owns the login and logout
confirmation pages. `POST /login` validates the antiforgery token and credentials,
opens an SSO session, and redirects; on failure it redirects back to `LoginPath`
with `?error=<code>&returnUrl=<orig>`. The host renders the GET login page and
surfaces the error code.
Grant types
The token endpoint dispatches each request to a registered `ICustomAuthGrantHandler`
(`Vefa.CustomAuth.AspNetCore.Endpoints.Grants`) keyed by `grant_type`. Built-in handlers cover:
- `authorization_code` (with PKCE)
- `refresh_token`
- `client_credentials` — confidential machine-to-machine clients. Requires a confidential
`TokenEndpointAuthMethod` and the per-client opt-in `CustomAuthClient.AllowClientCredentials`.
Issues an access token only (no ID token, no refresh token), with `sub` set to the client id.
Register an additional `ICustomAuthGrantHandler` to add a custom grant; a registration whose
`GrantType` matches a built-in grant overrides it (last registration wins).
Relying-Party Integration
The same package ships the client-side OpenID Connect integration so relying-party
applications do not have to hand-wire cookie and OpenID Connect authentication.
builder.Services.AddCustomAuthClient(options =>
{
options.Authority = "https://auth.example.com";
options.ClientId = "web-app";
options.AdditionalScopes.Add("sample-api");
});
app.MapCustomAuthSignOut("/logout");`AddCustomAuthClient` configures code flow with PKCE, saves tokens, and requests
`openid profile email offline_access` by default. `MapCustomAuthSignOut` pairs cookie
sign-out with the upstream OpenID Connect end-session call.
Security Notes
Keep PKCE enabled, use exact redirect URI matching, and configure HTTPS in production.
Refresh tokens require client refresh-token support and the `offline_access` scope. They are rotated on use, have sliding and absolute expiration, and detect reuse of consumed tokens.
The client credentials grant requires confidential client authentication (`private_key_jwt`); public clients cannot use it.