Защита SPA и API с помощью Azure AD и ролей приложений

Question

Я создаю систему, в которой SPA может вызывать API. SPA, а также API представлены в Azure AD с помощью регистрации приложений, которая требует назначения пользователей.

Во время назначения пользователю также назначается роль , которую предоставляет регистрация приложения. Доступные роли есть и в регистрации приложения SPA и API, и я назначаю пользователю одну и ту же роль в обеих регистрациях.

Регистрация API также предоставляет область, которую регистрация SPA использует для запроса маркеров доступа.

Роль из SPA используется для отображения различных элементов пользовательского интерфейса в зависимости от того, назначен ли пользователь или .

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

Я думаю, что эта диаграмма правильно отображает то, что происходит:

У меня есть пара вопросов по этому поводу, которые мне трудно понять, просто прочитав документацию.

Управление ролями в цепочке вызовов (SPA -> API)

Каков правильный способ распространения роли через систему? Должны ли все регистрации приложений иметь одни и те же роли, а пользователи должны вручную назначаться ролям в каждой регистрации?

Или я могу распространить роль, полученную пользователем при первом входе в SPA, или это нарушит безопасность JWT? Я предполагаю, что это нужно обрабатывать при каждой регистрации приложения, потому что ничто не помешает мне изменить исходящий запрос и установить роль вместо.

Роли и области

Я нашел этот ответ , который частично объясняет мне концепции. Я создаю внутреннюю систему, и мне не нужны никакие другие пользовательские данные, кроме OIDC. предоставляет (электронная почта, oid и так далее). SPA запрашивает эту область для отображения имени пользователя, вошедшего в систему.

Мои API никогда не потребуют от пользователя никакой другой информации, кроме этой. Нужны ли мне прицелы в этом случае?
Применяется ли согласие только к областям действия?
Является knownClientApplicationsа также preAuthorizedApplicationsприменимо только при использовании прицелов?

Прошу прощения, если это бессвязно, я прочитал так много документации, что не могу держать голову прямо.

Answer 1

Я совершенно забыл об этом, но проблема решена, и вот некоторая информация, которая, надеюсь, немного прояснит ситуацию для других.

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

Мы пошли вперед с ролями, так что об этом я и буду говорить. У нас есть одна регистрация приложения для нашего SPA и одна для нашего API. Роли должны быть определены при каждой регистрации приложения , роли не распространяются. Тот факт, что вы являетесь администратором в SPA, не означает, что вы являетесь администратором каждого API, поддерживающего SPA.

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

• Роли приложений определяются для каждого сервера ресурсов (API)
• Роли приложений явно назначаются каждому ресурсному серверу (API) и пользователю/группе.
• Роли приложения, релевантные (определяемые) для ресурса (идентифицируемого по запросу aud), выдаются в соответствующем токене.
• Тот факт, что пользователь A является администратором в API X, не означает, что этот пользователь автоматически становится администратором в API Y. Иное рассмотрение — плохой проект.
• Если пользователь A является администратором Z в API Z, это будет правильно отражено в токене, полученном через поток от имени в следующей (примерной/иллюстративной) цепочке:
  • Клиент B (например, SPA) требует авторизации через PKCE для пользователя A -> таким образом клиент B получает токен доступа к API X (в этом токене нет ролей) -> API X использует поток от имени для получения токена доступа к API Y (нет ролей в этом токене) -> (повторяйте этот шаг столько раз, сколько требует ваш дизайн) API Y получает токен доступа для API Z, используя поток от имени -> Токен доступа для API Z будет иметь роль администратора Z для Пользователь А.

В описанной выше цепочке вызовов от имени есть четыре (4) регистрации приложений:

1. Клиент Б (Клиент SPA)
2. API Х
3. API Y
4. API Z

API Z не волнует (и не должно волновать), какие роли и разрешения есть у пользователя в любой другой системе.

Роли и утверждения следуют только за ресурсом, для которого они определены, и никогда не будут включены в маркеры доступа для других ресурсов.

Если вы определяете роли приложения для зарегистрированного приложения клиента SPA, они будут присутствовать только в маркере идентификатора, полученном для клиента SPA, и ни в каком другом маркере.

Спорный вопрос, следует ли регистрировать несколько серверов ресурсов OAuth (регистрации приложений) или только один и работать с разными ролями и областями в рамках одной регистрации приложения. Возьмем, к примеру, MS Graph — на самом деле всего один ресурсный сервер, но сотни, если не тысячи областей и ролей приложений. И даже там тот факт, что Пользователь А имеетразрешение, не обязательно означает, что они должны иметь возможность читать почтовые сообщения взамен.