Токен доступа и идентификатор пользователя - PullRequest
Новая
       70

Токен доступа и идентификатор пользователя

1 голос
/ 06 апреля 2019

В настоящее время я пытаюсь аутентифицировать приложение angular 7 с помощью ADFS 2016 (используя angular-oauth2-oidc).Пока это работает довольно хорошо.Когда я получаю доступ к приложению, меня перенаправляют на страницу входа в ADFS, где я ввожу свои учетные данные и получаю токены.

Теперь, когда приложение вызывает веб-API, оно отправляет токен доступа в заголовках запроса.Маркер доступа, возвращаемый ADFS, выглядит следующим образом: 

{
  "aud": "microsoft:identityserver:xxx",
  "iss": "http://xxx/adfs/services/trust",
  "iat": 1554561406,
  "nbf": 1554561406,
  "exp": 1554565006,
  "apptype": "Public",
  "appid": "xxx",
  "authmethod": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
  "auth_time": "2019-04-06T12:21:39.222Z",
  "ver": "1.0",
  "scp": "profile openid"
}

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

Однако я читаю здесь , который

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

Но по умолчанию ADFS не предоставляет «вспомогательный» токен.Верно ли, если я сам добавляю претензию «sub», содержащую адрес электронной почты пользователя, или мне нужно действовать по-другому?

1 Ответ

2 голосов
/ 06 апреля 2019

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

Стандартный способ - запросить область действия profile (которую вы сделали) и получить информацию от конечной точки userinfo (см. OpenID Connect RFC ). Если вы используете этот способ, вы можете кэшировать ответ, поэтому вам не нужно делать этот HTTP-вызов при каждом клиентском запросе.

Если ваш бэкэнд-API используется только приложением Angular и не должен вызываться третьими лицами, вы также можете рассмотреть возможность использования бэкэнда в качестве клиента OAuth2, который получает код авторизации и обменивает его на токен ID. Затем он может сохранить идентификационную информацию пользователя (считанную из идентификатора токена) в сеансе и создать файл cookie, идентифицирующий сеанс. Таким образом, клиенту не нужно будет отправлять токен на каждый запрос. Это сделало бы бэкэнд с состоянием, но его было бы проще реализовать.

...