Отсутствуют области разрешений приложений в токене JWT Azure AD - PullRequest
Новая
       29

Отсутствуют области разрешений приложений в токене JWT Azure AD

0 голосов
/ 08 мая 2018

Наше приложение управляет календарями Office 365, не требуя явного согласия пользователей, использующих API Office 365 Exchange Online. Это работает, как и ожидалось, для существующих установок у клиентов, но для нового клиента все запросы к API Exchange Online возвращают ответ 401 Unauthorized. Мы сузили это до требования о ролях, отсутствующего в токене JWT.

Наш вопрос заключается в том, является ли эта заявка роли отсутствующей в JWT ошибкой, или это было сделано по замыслу. Возможно, кто-то из команды Azure AD сможет поделиться своими мыслями.

Как воспроизвести

В Azure AD мы создали регистрацию приложения. Открытый ключ был загружен для аутентификации через ADAL4j. Кроме того, Exchange Online были предоставлены некоторые разрешения для приложений:

application permissions

Мы можем успешно запросить токен доступа через ADAL4j, используя https://outlook.office365.com/ в качестве идентификатора ресурса. JWT выглядит примерно так (убрал некоторую нерелевантную информацию): 

{
    typ: "JWT",
    alg: "RS256",
},
{
    aud: "https://outlook.office365.com/",
    iss: "https://sts.windows.net/yyy/",
    app_displayname: "Test",
    appid: "app-id",
    ver: "1.0"
}

Как видно, свойство roles отсутствует в токене JWT.

При вызове Exchange Online API (например, https://outlook.office365.com/api/v2.0/users/user@tenant.onmicrosoft.com/calendars) при отправке JWT в качестве токена на предъявителя возвращается 401 Unauthorized. Заголовок x-ms-diagnostics упоминает: 

2000008;reason="The token contains no permissions, or permissions can not be understood.";error_category="invalid_grant"

Ожидаемое поведение

При использовании старой регистрации приложения (созданной с помощью классического портала Azure, если я правильно помню) JWT содержит свойство Roles с ролью, которую мы запросили: 

{
    typ: "JWT",
    alg: "RS256",
},
{
    aud: "https://outlook.office365.com/",
    iss: "https://sts.windows.net/yyy/",
    app_displayname: "Test",
    appid: "app-id",
    roles: [
        "Calendars.ReadWrite.All"
    ],
    ver: "1.0"
}

Использование этого JWT в качестве токена Bearer при вызове Exchange Online API работает должным образом.

Обход

Мы решили эту проблему, используя кнопку «Предоставить разрешения» для регистрации нового приложения:

grant permissions button

Теперь в JWT присутствует роль Calendars.ReadWrite.All, поэтому все работает, как и ожидалось.

Вопрос

В прошлом нам никогда не приходилось выполнять действие «Предоставление разрешений». Также эта страница упоминает (выделение добавлено):

Как администратор, вы также можете дать согласие на делегированные разрешения от имени всех пользователей вашего арендатора. Административное согласие предотвращает появление диалога согласия каждый пользователь в клиенте, и может быть сделано на портале Azure пользователями с ролью администратора. На странице настроек для вашего приложения, нажмите кнопку «Необходимые разрешения» и нажмите кнопку «* 1057» Разрешения кнопка

Однако разрешение «Чтение и запись календарей во всех почтовых ящиках» является разрешением для приложения , а не разрешением делегированным , как указано на этой странице .

Является ли обходной путь правильным решением проблемы с отсутствующими утверждениями ролей или что-то еще не так на стороне Azure AD?

1 Ответ

0 голосов
/ 08 мая 2018

Обходной путь - правильное решение. Когда вашему приложению требуются разрешения приложения, администратор должен дать согласие, нажав кнопку «Предоставить разрешения» (как вы это сделали) или передавая admin_consent по URL-адресу входа. Это относится к модели приложения AAD v1. Для модели приложения AAD v2 существует другой способ получения согласия администратора. Больше информации здесь .

В прошлом (Azure Classic Portal), когда вы добавляли в приложение разрешения для приложения, согласие предоставлялось автоматически. Это не относится к новому порталу Azure.

...