Authlink.Auth.ServiceStack 2.1.0

📦 Overview

Authlink.Auth.ServiceStack enables secure token-based authentication in ServiceStack applications using the IIdentityClient abstraction from Authlink.Identity.Client.Core.

It allows your ServiceStack APIs to:

• Authenticate users via your Authlink Identity Provider
• Automatically resolve user claims and populate sessions
• Support access and refresh token flows via OIDC

🚀 Installation

dotnet add package Authlink.Auth.ServiceStack

Or via NuGet Package Manager:

PM> Install-Package Authlink.Auth.ServiceStack

🔧 Usage Example

In your AppHost.cs:

var client = Container.GetRequiredService<IIdentityClient>();

var provider = new JwtAuthProviderReader(
    "https://identity.authlink.co.za",
    ["https://api.example.com"],
    "client-id",
    client);

Plugins.Add(new AuthFeature(() => new AuthUserSession(), [provider]));

⚙️ Configuration

provider.RequireSecureCookies = !environment.IsDevelopment();
provider.ClockSkew = TimeSpan.FromMinutes(2);
provider.JwksRefreshInterval = TimeSpan.FromMinutes(15);

🔑 JWKS caching & key rotation

The provider keeps an immutable in-memory snapshot of the Identity Provider's signing keys and validates tokens locally. The JWKS endpoint (/api/connect/jwks) is only contacted when:

• the cache has not yet been populated (cold start);
• JwksRefreshInterval has elapsed since the last successful refresh;
• a token references a kid that is not in the current snapshot (throttled by UnknownKidRefreshThrottle).

Requests without a JWT never contact the Identity Provider. Concurrent refreshes are coalesced into a single fetch, and if a refresh fails the previous valid snapshot continues to be served while further attempts are suppressed for FailedRefreshBackoff, so an outage cannot amplify into one JWKS call per request. Malformed keys in a JWKS response are skipped individually rather than failing the refresh.

Because the Identity Provider announces new signing keys as pending in JWKS ahead of activation (a propagation period), a snapshot refreshed within that window will already contain the next key before any token is signed with it, so unknown-kid refreshes are rare in normal rotation. Note that emergency key revocation propagates on the next interval refresh rather than instantly.

📚 Documentation

Coming soon at: https://docs.authlink.co.za

📄 License

MIT