Azure AD. .Net Core 2 - Как использовать два разных идентификатора клиента? - PullRequest
Новая
       19

Azure AD. .Net Core 2 - Как использовать два разных идентификатора клиента?

0 голосов
/ 09 октября 2018

Итак, у нас есть веб-API, который отлично работает с Azure AD и аутентификацией токенов на предъявителя.

В моих ConfigureServices у меня есть это: 

services.AddAuthentication(sharedOptions =>
{
    sharedOptions.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.Audience = Configuration["Azure:AD:ClientId"];
    options.Authority = $"{Configuration["Azure:AD:Instance"]}{Configuration["Azure:AD:TenantId"]}";
});

У нас есть настройка идентификатора клиентабыть приложением Web API в Azure AD.

Теперь мы создаем собственное приложение, и нам нужно также иметь собственный идентификатор клиента приложения в Azure AD.Мой API ищет клиента Web API ... как мне также разрешить токен на предъявителя, который был создан с собственным приложением?

Ответы [ 2 ]

0 голосов
/ 09 октября 2018

Хорошо!Итак ... у нас все получилось.

Для потомков вот что мы в итоге сделали.

Мы нашли эту прекрасную ссылку: https://github.com/Azure-Samples/active-directory-dotnet-webapi-manual-jwt-validation

На шаге 2это говорит о том, что вам нужно изменить URI веб-API. В итоге нам не нужно было это делать ...

Что было критически важно, так это добавить разрешение из приложения Native в веб-API (второй наборшагов в # 2).По сути, насколько я понимаю, это позволяет нативному приложению и приложению веб-API работать совместно и совместно использовать идентификатор клиента, когда речь идет о перспективе аутентификации.

Мы также обнаружили, что редактирование манифеста в родном приложении иmake "oauth2AllowImplicitFlow" = true также был важен.

Надеюсь, это кому-нибудь поможет.

0 голосов
/ 09 октября 2018

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

В токенах формата v1.0 они также имеют утверждение appid, которое представляет идентификатор приложения клиентского приложения (например, вашего веб-приложения или нативного приложения), если ваш API пытается проверить, что токен былвыдан одному из ваших клиентов.

В токенах v2.0 это утверждение azp.

Обратите внимание, что в случае нативного приложения оно считается публичным клиентом, что означаетТочная личность клиента не гарантируется, отсюда и название публичного клиента.Ваше веб-приложение является конфиденциальным клиентом, поэтому есть надежная гарантия, что заявка appid будет приложением, на которое она претендует.

В обоих форматах есть еще одно утверждение (appidacr и azpacr соответственно), которое представляет тип клиента.Вы можете иметь высокую степень достоверности, если значение равно 1 или 2, но следует соблюдать осторожность в случае, если оно равно 0.

Ссылка на токены

...