Разный поток для разных конечных точек веб-API

Как настроить конечные точки веб-API для использования различных типов грантов, поступающих от IdentityServer?

Прямо сейчас у меня для запуска есть:

app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions()
{
   Authority = "http://localhost:5000",
   RequiredScopes = new[] { "public", "read", "write" }
});

Контроллер:

// Assuming to access this endpoint you need to have client id/secret (client credential flow)
public IEnumerable<string> Get()
{
   return new string[] { "value1", "value2" };
}

// Assuming to access this endpoint you need to have username/password (password flow)
[ResourceAuthorization("read")]
public string Get(int id)
{
   return "value";
}

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

Это плохая структура?

Должен ли я просто отделить публичный API (поток учетных данных), конечные точки потока паролей и внутренние конечные точки (не подвергать внешней инфраструктуре компании) различным проектам?

Как указать область действия для разных конечных точек? (например, одна конечная точка должна быть общедоступной, а другая — прочитанной)


person gnaungayan    schedule 25.01.2017    source источник


Ответы (1)


Это очень плохо. Вы связываете проблемы с потоком аутентификации с вашим API. Вместо этого определите разные области для каждого клиента и используйте эти области, чтобы ограничить, какие клиенты могут использовать какие ресурсы. Вы можете выполнять авторизацию на основе утверждений в зависимости от области действия. Проверьте это.

person Lutando    schedule 25.01.2017
comment
Но что, если клиент аутентифицируется с помощью клиентского потока? Будет ли еще работать ResourceAuthorization? - person gnaungayan; 26.01.2017
comment
Как я понял, ResourceAuthorization следует использовать, если у вас есть пользователь, что означает, что клиент входит в систему с использованием потока пароля и использует ScopeAuthorization, если пользователь не участвует. Глядя на ScopeAuthorization, он говорит, что он устарел, поэтому я должен использовать первый? - person gnaungayan; 26.01.2017
comment
comment
Он по-прежнему должен работать, все эти атрибуты авторизации проверяют, существуют ли эти утверждения в токене носителя, область действия точно так же отображается как утверждение в JWT. - person Lutando; 26.01.2017