Может ли проект WebAPI разместить несколько API?

Question

Игнорирование пользователя и сосредоточение внимания на клиенте - для защиты проекта WebAPI с ID4 вы можете добавить промежуточное программное обеспечение аутентификации токена, а затем:

.AddIdentityServerAuthentication(options =>
            {
                options.Authority = "http://localhost:5000";
                options.RequireHttpsMetadata = false;

                options.ApiName = "api1";
            });

Можно ли использовать тот же проект WebAPI дляобеспечить дополнительный API?

.AddIdentityServerAuthentication(options =>
            {
                options.Authority = "http://localhost:5000";
                options.RequireHttpsMetadata = false;

                options.ApiName = "api2";
            });

Или это соотношение между ResourceAPI и "хост-проектом WebAPI" 1 к 1?

В принципе, на уровне клиента мне было бы интересно, если бы вы могли создать несколько API для разных клиентовно используйте тот же хост-проект WebAPI.

Answer 1

Давайте рассмотрим ресурс как логический источник , который необходимо защитить.

Это означает, что ресурс не привязан к одному WebApi, но WebApi привязан к одномуресурс.Вы можете создать группу WebApi, которые вместе образуют ресурс.Или вы можете просто добавить полный исходный код в один WebApi.

Тогда нет смысла размещать несколько ресурсов в одном WebApi.Если он не принадлежит ресурсу, создайте отдельные WebApi.

Однако, если он принадлежит одному и тому же ресурсу и вы хотите разделить ресурс на логические части, используйте scopes вместо этого.

Вы можете добавить несколько областей к одному ресурсу:

resource = Api0
    scope = Api1.Read
    scope = Api1.Write
    scope = Api2.Read
    scope = Api2.Write

Обратите внимание, что я использовал «Api0» в качестве имени ресурса (options.ApiName).Где ApiX может быть логическим разделением для каждого клиента.

Теперь я могу создавать отдельные WebApi, которые являются частью одного и того же ресурса (все они имеют options.ApiName = "Api0"), или один WebApi.

В случаеиз отдельных API, где каждый Api реализует одну область, я могу использовать что-то вроде этого:

services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddIdentityServerAuthentication(options =>
    {
        options.Authority = "http://localhost:5000";
        options.RequireHttpsMetadata = false;

        options.ApiName = "Api0";

        options.JwtBearerEvents = new JwtBearerEvents
        {
            OnTokenValidated = context =>
            {
                if (!context.Principal.HasClaim("scope", "Api1.Read"))
                    context.Fail("Invalid Scope");
                return Task.CompletedTask;
            }
        };
    });

В то время как в случае одного WebApi с несколькими областями я могу использовать Политики:

services.AddMvcCore()
...
.AddAuthorization(p =>
{
    p.AddPolicy("Api1.Read", (policy) => policy.RequireScope("Api1.Read"));
    p.AddPolicy("Api1.Write", (policy) => policy.RequireScope("Api1.Write"));
    p.AddPolicy("Api2.Read", (policy) => policy.RequireScope("Api2.Read"));
    p.AddPolicy("Api2.Write", (policy) => policy.RequireScope("Api2.Write"));
});

Где вы можете использовать AuthorizeAttribute:

[Authorize("Api1.Read")]

Обратите внимание, что scope! = Resource.Клиент запрашивает одну или несколько областей, например, "Api1.Read Api1.Write", но ресурс проверяется по имени (аудитория = Api0).

События, политики, промежуточное программное обеспечение могут использоваться для более точной авторизации.