Эта страница ещё не переведена.

Configuration and Setup

Introduction

This guide walks through configuring Abblix OIDC Server in a .NET project, on the free tier or with a purchased license. It covers package installation and the licensing options you can choose between, so you can get the project running quickly and predictably.

Install Abblix NuGet Package

Abblix delivers its OIDC Server as a set of NuGet packages available on nuget.org.

Open a terminal or command prompt in the root directory of your solution.

Run the following command to install the package:

Bash

dotnet add package Abblix.OIDC.Server.Mvc

or for a specific version:

Bash

dotnet add package Abblix.OIDC.Server.Mvc --version <version_number>

This will add the package reference directly to your project file.

Apply the License

Without a license

If you skip this step, the server runs on the free tier: one issuer, and no limit on client applications, users or nodes. Every protocol and profile is available, as it is on every tier. The server counts the distinct issuer identifiers it sees at runtime. Where OidcOptions.Issuer is left unset, the identifier is derived from the incoming request, so a second hostname reaching the server - an internal load-balancer name, a health check on a pod address, a regional hostname - counts as a second issuer. Past the limit every request throws InvalidOperationException with the message "The license terms violation detected", on every issuer including the first, until the process restarts. Only the log record is throttled, to one entry per fifteen minutes per issuer. Set OidcOptions.Issuer explicitly in production.

You do not need a license key to stay within the free tier. A paid license is what you buy when your company passes the free thresholds, or when you need more than one production issuer; see the pricing page for both.

There are several different options to apply your Abblix OIDC Server license. Pick whichever is most convenient:

Use Inline License Configuration

This method sets the license key directly in your application's startup configuration. You can retrieve the key from environment variables, configuration files, or a secure vault, then assign it to OidcOptions.LicenseJwt in the options delegate you pass to AddOidcServices:

builder.Services.AddOidcServices(options =>
{
    options.LicenseJwt = "<your_license_key_here>";
});

The advantage of this approach is its simplicity.

Implement ILicenseJwtProvider

This method is more flexible: implement the ILicenseJwtProvider interface to obtain the license dynamically. The custom implementation of ILicenseJwtProvider can rely on services configured during startup to obtain the license. It also supports loading multiple licenses simultaneously, which lets you migrate from an old license to a new one without downtime when both are loaded.

Write a class implementing ILicenseJwtProvider, which lives in Abblix.Oidc.Server.Features.Licensing and declares a single method, GetLicenseJwtAsync, returning a nullable IAsyncEnumerable<string>. The sequence is where several licenses come from; returning nothing leaves the server on the free tier. The body is yours: read an environment variable, call a vault, query a database.
Register your implementation as a singleton for ILicenseJwtProvider in Program.cs before the AddOidcServices call. The built-in provider that reads OidcOptions.LicenseJwt is registered with TryAddSingleton, so it steps aside for yours.
C#
```
builder.Services.AddSingleton<ILicenseJwtProvider, CustomLicenseJwtProvider>();
builder.Services.AddOidcServices(options => { /* configure as needed */ });
```

Register OIDC Services in Program.cs

With the package installed and the license configured, four registrations in Program.cs are what the server needs to start, alongside the usual AddControllersWithViews of an MVC application.

AddOidcServices from Abblix.Oidc.Server.Mvc is the entry point: its options delegate is where clients, the login URI, signing keys and everything else are configured, and the call itself brings in the protocol endpoints and the MVC controllers that serve them.

Cookie authentication, registered through AddAuthentication and AddCookie, is what the server signs the user in with once the login has succeeded.

A distributed cache is needed because authorization codes, pushed authorization requests and JWT statuses are persisted through IDistributedCache. AddDistributedMemoryCache is enough while developing; production wants a real backend behind that interface - Redis, SQL Server, NCache, Memcached, Couchbase.

In the request pipeline, UseCors has to come after UseRouting, and this one is not a matter of taste: the protocol controllers carry CORS metadata, because browser-based clients read the discovery document, the key set and the token endpoint cross-origin, and ASP.NET Core routing refuses to serve an endpoint whose CORS metadata no middleware honours. Without that call the endpoints carrying that metadata answer 500. The policy itself is registered for you; only the middleware call belongs to the host. Add UseAuthorization and the default controller route as in any MVC application.

That is the smallest setup that will boot the server. For a full end-to-end walkthrough (defining clients, building a login UI, plugging in user storage, and connecting a client application), follow the Getting Started guide.

Finalizing the Setup

Verify Setup

Ensure the application runs without any licensing errors.
Check that the issuer identifier the server reports in discovery is the one you expect.

For advanced configurations, contact our support team.

Getting Started

Securing a React SPA (BFF)