Управление доступом к потоку учетных данных клиента OAuth Azure AD

Вы можете определить «роли» как для пользователей, так и для приложений в манифесте вашего API в Azure AD.

Роли приложений на самом деле являются разрешениями приложений, если вам интересно.

Таким образом, у вас может быть что-то вроде этого в вашем манифесте API (другие свойства удалены для ясности):

{
  "appRoles": [
    {
      "allowedMemberTypes": [
        "Application"
      ],
      "displayName": "Read all things",
      "id": "32028ccd-3212-4f39-3212-beabd6787d81",
      "isEnabled": true,
      "description": "Allow the application to read all things as itself.",
      "value": "Things.Read.All"
    },
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Read things",
      "id": "ef8d02ff-eee1-6745-9387-96587c358783",
      "isEnabled": true,
      "description": "Allow the user to read things.",
      "value": "Things.Read"
    }
  ]
}

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

Затем вы можете предоставить пользователям роль «Читать все», а консольному приложению демона - разрешение «Читать все». И вы реализуете оба сценария :)

Вы добавляете роль пользователям / группам, перейдя в Корпоративные приложения-> Ваш API-> Пользователи и группы-> Добавить пользователя. Выберите нужных пользователей / группы, а затем выберите для них роль (если у вас только одна, она будет выбрана заранее).

Вы добавляете разрешение приложения, находя другое приложение Регистрация приложения-> Требуемые разрешения-> Добавить-> Найдите свой API-> Выбрать-> Проверить разрешение приложения, которое вы определили ранее, из списка. Затем вы можете нажать кнопку «Предоставить разрешения», чтобы назначить роль приложения.

Затем вы получите значение в заявке на роли для любого сценария.

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

"roles": [
    "Things.Read"
  ],

и так во втором сценарии:

"roles": [
    "Things.Read.All"
  ],

Вы можете получить роль приложения, как вы упомянули, с токеном, который вы получаете на стороне клиента. Но на стороне сервера (защищенная сторона API) нет возможности увидеть утверждения ролей для авторизации.

С помощью User / Roles вы можете создать сопоставление между пользователями и ролями, определенными в файле манифеста. Таким образом, UI и API будут знать роли пользователей для авторизации.

С помощью приложения / ролей на портале Azure невозможно создать сопоставление clientId / clientSecret с AppRole, определенным в Manifest.