Блог

У меня есть ASP.NET Проект Core 3.1, подобный этому примеру: войдите в систему пользователя с помощью платформы Microsoft Identity Platform в настольном приложении WPF и вызовите ASP.NET Основной веб-API.

Я использую Identity web версию 1.0 и Azure AD, однопользовательское приложение.

Я отредактировал добавление манифеста appRoles , поскольку запрашиваю только токен приложения, а не токен пользователя:

 [... more json ...]
"appId": "<guid>",
"appRoles": [
    {
        "allowedMemberTypes": [
            "Application"
        ],
        "description": "Accesses the application.",
        "displayName": "access_as_application",
        "id": "<unique guid>",
        "isEnabled": true,
        "lang": null,
        "origin": "Application",
        "value": "access_as_application"
    }
],
"oauth2AllowUrlPathMatching": false,
[... more json ...]
  

Я также включил idtyp требование маркера доступа, чтобы указать, что это токен приложения.:

 [... more json ...]
"optionalClaims": {
    "idToken": [],
    "accessToken": [
        {
            "name": "idtyp",
            "source": null,
            "essential": false,
            "additionalProperties": []
        }
    ],
    "saml2Token": []
[... more json ...]
  

Следующий запрос выполняется с помощью Postman . Пожалуйста, обратите внимание на использование /.default с областью видимости, которое упоминается в документации в отношении потока предоставления учетных данных клиента.

 POST /{tenant_id}/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

scope=api:/%2{client_id}/.default
amp;client_id={client_id}
amp;grant_type=client_credentials
amp;client_secret={secret_key}
  

Запрос возвращает access_token значение, которое можно просмотреть с помощью jwt.ms и выглядит примерно так, где фактические данные были заменены заполнителями по соображениям безопасности.:

 {
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "[...]",
  "kid": "[...]"
}.{
  "aud": "api://<client_id>",
  "iss": "https://sts.windows.net/<tenant_id>/",
  "iat": 1601803439,
  "nbf": 1601803439,
  "exp": 1601807339,
  "aio": "[...]==",
  "appid": "<app id>",
  "appidacr": "1",
  "idp": "https://sts.windows.net/<tenant_id>/",
  "idtyp": "app",
  "oid": "<guid>",
  "rh": "[..].",
  "roles": [
    "access_as_application"
  ],
  "sub": "<guid>",
  "tid": "<guid>",
  "uti": "[...]",
  "ver": "1.0"
}
  

I notice that the token above does not include scp . This seem correct as this is an application token and not a user token. Instead it includes `”roles”´ as appropiate for an application token.

The access_token can now be used as bearer in a Postman Get:

 GET /api/myapi
Host: https://localhost:5001
Authorization: Bearer {access_token}
  

The reponse to this request is 500 internal error . I.e. something is wrong. The access_token looks like a corrent application token, so the error seems to be on the ASP.NET Core 3.1 controller side.

The ASP.NET Core 3.1. project hosting the custom API, has a startup.cs which includes the following code:

 services.AddMicrosoftIdentityWebApiAuthentication(Configuration);

// This is added for the sole purpose to highlight the origin of the exception.
services.Configure<JwtBearerOptions>(JwtBearerDefaults.AuthenticationScheme, options =>
{
    var existingOnTokenValidatedHandler = options.Events.OnTokenValidated;
    
    options.Events.OnTokenValidated = async context =>
    {
        if (context.Principal.Claims.All(x => x.Type != ClaimConstants.Scope)
            amp;amp; context.Principal.Claims.All(y => y.Type != ClaimConstants.Scp)
            amp;amp; context.Principal.Claims.All(y => y.Type != ClaimConstants.Roles))
        {
            // This where the exception originates from:
            throw new UnauthorizedAccessException("Neither scope or roles claim was found in the bearer token.");
        }
    };
});
  

appsettings.json Для проекта включает:

 "AzureAD": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "mydomain.onmicrosoft.com",
    "ClientId": "<client_id>",
    "TenantId": "<tenant_id>",
    "Audience": "api://<client_id>"
},
  

… и контроллер выглядит так:

 [Authorize]
[Route("api/[controller]")]
public class MyApiController : Controller
{
    [HttpGet]
    public async Task<string> Get()
    {
        return "Hello world!";
    }
}
  

Основная причина 500 internal error заключается в том, что это исключение генерируется: IDW10201: Neither scope or roles claim was found in the bearer token. exception .

Обновить:

(Пожалуйста, смотрите Ответ ниже для получения более подробной информации).

Это видео на тему «Внедрение авторизации в ваших приложениях с помощью платформы Microsoft identity platform — июнь 2020» предполагает, что недостающим элементом является этот флаг JwtSecurityTokenHandler.DefaultMapInboundClaims = false; , который необходимо установить, startup.cs например:

 public void ConfigureServices(IServiceCollection services)
{
    // By default, the claims mapping will map clain names in the old format to accommodate older SAML applications.
    //'http://schemas.microsodt.com/ws/2008/06/identity/clains/role' instead of 'roles'
    // This flag ensures that the ClaimsIdentity claims collection will be build from the claims in the token
    JwtSecurityTokenHandler.DefaultMapInboundClaims = false;
    
    [...more code...]

  

Это может помочь, если вы планируете не использовать встроенную область видимости или роли. Вы можете включить аутентификацию «список контроля доступа», используя мой пример для Azure B2C ниже. Вот несколько ссылок на официальную документацию.

https://github.com/AzureAD/microsoft-identity-web/wiki/web-apis#user-content-web-apis-called-by-daemon-apps-using-client-credential-flow

https://learn.microsoft.com/en-us/dotnet/api/microsoft.identity.web.microsoftidentityoptions .allowwebapitobeauthorizedbyacl?view=azure-dotnet-preview

Добавьте следующее в свою конфигурацию AD: "AllowWebApiToBeAuthorizedByACL": true

Пример:

 "AzureAdB2C": {
    "Instance": "https://xxx.b2clogin.com/",
    "ClientId": "xxxx",
    "Domain": "xxx.onmicrosoft.com",
    "SignUpSignInPolicyId": "xxx",
    "AllowWebApiToBeAuthorizedByACL": true
  },
  

Что означает список ACL / Access-control:
ACL: https://en.wikipedia.org/wiki/Access-control_list

В видео «Внедрение авторизации в ваших приложениях с помощью платформы Microsoft identity platform — июнь 2020 года» указывается, что недостающим элементом является этот флаг JwtSecurityTokenHandler.DefaultMapInboundClaims = false; , который необходимо установить, startup.cs например:

 public void ConfigureServices(IServiceCollection services)
{
    services.AddMicrosoftIdentityWebApiAuthentication(Configuration);

    // By default, the claims mapping will map claim names in the old format to accommodate older SAML applications.
    //'http://schemas.microsodt.com/ws/2008/06/identity/clains/role' instead of 'roles'
    // This flag ensures that the ClaimsIdentity claims collection will be build from the claims in the token
    JwtSecurityTokenHandler.DefaultMapInboundClaims = false;


    // Notice that this part is different in the video, 
    // however in this context the following seems to be 
    // the correct way of setting the RoleClaimType:
    services.Configure<JwtBearerOptions>(JwtBearerDefaults.AuthenticationScheme, options =>
    {
        // The claim in the Jwt token where App roles are available.
        options.TokenValidationParameters.RoleClaimType = "roles";
    });

    [... more code ...]
}

  

Альтернатива 1

Также можно установить авторизацию для всего приложения следующим образом в startup.cs :

 
services.AddControllers(options =>
{
    var policy = new AuthorizationPolicyBuilder()
        .RequireClaim("roles", "access_as_application")
        .Build();
    options.Filters.Add(new AuthorizeFilter(policy));
});
  

Альтернатива 2

Также можно использовать политику, подобную этой:

 services.AddAuthorization(config =>
{
    config.AddPolicy("Role", policy => 
        policy.RequireClaim("roles", "access_as_application"));
});
  

Теперь эта политика может использоваться для запроса контроллера, подобного этому:

 [HttpGet]
[Authorize(Policy = "Role")]
public async Task<string> Get()
{
    return "Hello world!";
}
  

Подробнее в документации: проверки ролей на основе политики.

Просто добавьте DefaultMapInboundClaims в конфигурацию вашей службы API

 public void ConfigureServices(IServiceCollection services)
{
    JwtSecurityTokenHandler.DefaultMapInboundClaims = false;
}
  

Когда я получил эту ошибку «IDW10202», это было из-за этой строки кода в контроллере.

HttpContext.ValidateAppRole("MyAppRole");

(Это был единственный результат, возвращенный Google, поэтому разместите этот комментарий здесь для чьей-либо пользы. Извиняюсь, если немного не по теме.)

Причина в том, что вы делаете запрос с областью по умолчанию scope=api:/%2{client_id}/.default , которая не включает утверждение области видимости в access_token. вы должны использовать определенную область, в которой вы зарегистрированы для своего ASP.NET Проект API Core 3.1, когда вы предоставляете этот API на портале Azure.