Следует ли использовать идентификатор или маркер доступа для авторизации функций SPA?

Контекст

У меня есть одностраничное приложение, которое взаимодействует с серверным REST API. Этот REST API создан специально для обслуживания SPA. Чтобы перемещаться или использовать какие-либо функции SPA за пределами домашней страницы, пользователи должны сначала войти в систему. Я использую OIDC с Okta для аутентификации пользователей. Пользователи могут иметь роль администратора или пользователя. Их роль будет использоваться для авторизации, на какие SPA-страницы им разрешено переходить и какие вызовы REST API им разрешено делать.

Вопросов

  1. После того, как пользователь входит в систему, мое приложение получает токен идентификатора и токен доступа от Okta. У меня есть возможность включить роль пользователя в качестве настраиваемого утверждения либо в токен идентификатора, либо в токен доступа. В какой токен следует включать эту информацию? Оба?

  2. Пользовательский интерфейс должен принимать некоторые решения об авторизации в зависимости от роли пользователя. Например, какие элементы HTML отображать или скрывать и по каким маршрутам SPA можно перемещаться. Следует ли принимать эти решения, проверяя токен идентификатора или токен доступа? Другой?

  3. При вызове моего серверного API через SPA должен ли я пересылать токен идентификатора и токен доступа, полученные моим SPA? Только токен доступа? Или мне следует настроить другой сервер авторизации для моего внутреннего REST API и попросить мой SPA обратиться за другим токеном доступа?


authentication authorization oauth-2.0 openid-connect okta
person jmrah    schedule 18.07.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Некоторые ответы:

  1. Маркер id - это просто утверждение SPA о том, что пользователь аутентифицирован. Если вы собираетесь поместить роль в токен, используйте токен доступа, предназначенный для авторизации.

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

  3. Отправляйте только токен доступа в API, что является стандартным рекомендуемым поведением.

ОБЯЗАННОСТИ

В целом:

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

Если вы хотите использовать информацию о роли как в пользовательском интерфейсе, так и в API, то по умолчанию можно добавить роль как в токен идентификатора, так и в токен доступа.

Однако это плохо масштабируется, поскольку в реальном бизнес-приложении вы, вероятно, со временем добавите несколько похожих правил и по-прежнему будете нуждаться в добавлении утверждений к токенам.

РАСШИРЕНИЕ

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

Кроме того, токены не обязательно должны быть единственным источником данных для решений об авторизации, принимаемых пользовательскими интерфейсами и API. В моем сообщении в блоге о претензиях описывается шаблон, который можно использовать для управления претензии с течением времени из нескольких источников данных.

person Gary Archer    schedule 19.07.2020
comment
По поводу ответа №2. Вы предлагаете, чтобы вместо того, чтобы пользовательский интерфейс принимал решения пользовательского интерфейса (например, что показывать или скрывать) на основе содержимого токена, он должен вместо этого вызывать API, чтобы узнать, какая роль находится в токене доступа? - person jmrah; 19.07.2020
comment
Я обновил свой исходный ответ. Если вы хотите, чтобы пользовательский интерфейс считывал роль из токена, вы должны добавить его в токен идентификатора. Однако API также потребуется роль, и в этом случае вам может потребоваться также добавить ее в токен доступа. - person Gary Archer; 19.07.2020
comment
Спасибо, Гэри. Ваши ответы ясны, и спасибо за намек на альтернативу, о которой я никогда не думал. Я сейчас читаю ваш блог, и он очень информативен. - person jmrah; 19.07.2020