Централизованная конечная точка авторизации и аутентификации с использованием AspNet.Security.OpenIdConnect.Server (OIDC)

Разделение роли сервера ресурсов (то есть API) от роли сервера авторизации определенно возможно с помощью ASOS.

При выборе токенов JWT (вместо зашифрованных токенов по умолчанию) вам необходимо убедиться, что аудитория правильно добавлена ​​к билету аутентификации, вызвав ticket.SetResources, чтобы токен доступа JWT получил соответствующее aud утверждение, содержащее идентификатор, связанный с вашим сервером ресурсов. (т.е. API):

public override Task GrantResourceOwnerCredentials(GrantResourceOwnerCredentialsContext context) {
    var identity = new ClaimsIdentity(context.Options.AuthenticationScheme);
    identity.AddClaim(ClaimTypes.NameIdentifier, "[unique identifier]");

    var ticket = new AuthenticationTicket(
        new ClaimsPrincipal(identity),
        new AuthenticationProperties(),
        context.Options.AuthenticationScheme);

    // Call SetResources with the list of resource servers
    // the access token should be issued for.
    ticket.SetResources("resource_server_1");

    // Call SetScopes with the list of scopes you want to grant.
    ticket.SetScopes("profile", "offline_access");

    context.Validate(ticket);

    return Task.FromResult(0);
}     

В вашем приложении API вам просто нужно установить свойство options.Audience с идентификатором, используемым на сервере авторизации, и оно должно работать:

app.UseJwtBearerAuthentication(new JwtBearerOptions {
    AutomaticAuthenticate = true,
    AutomaticChallenge = true,
    Audience = "resource_server_1",
    Authority = "http://localhost:61854"
});

У меня был бы небольшой фрагмент кода при вызове app.UseJwtBearerAuthentication, просто указывая промежуточное ПО JWT на конечную точку OIDC? Если это так, с app.UseJwtBearerAuthentication, который использует OIDC, чтобы позволить IdentityModel использовать HTTP, все еще происходит немного волшебства, поэтому я не понимаю, понадобится ли мне это и на подчиненных серверах.

По промежуточного слоя носителя JWT автоматически получает криптографический ключ, используемый для подписи токена доступа, с сервера авторизации, указанного в свойстве options.Authority, путем HTTP-вызова конечной точки метаданных конфигурации: вам не нужно ничего настраивать, даже если проект API отделен от приложения сервера авторизации .