REST Проверка токена в бизнес-API, сгенерированного сервисом аутентификации - PullRequest
Новая
       24

REST Проверка токена в бизнес-API, сгенерированного сервисом аутентификации

0 голосов
/ 03 ноября 2018

У меня есть два разных REST API, скажем, API аутентификации и бизнес-API, размещенные в Windows Azure.

API аутентификации отвечает за аутентификацию пользователя с помощью WsFederation или OpenID или пользовательской аутентификации

Бизнес-API отвечает за выполнение бизнес-логики. Только законный пользователь должен иметь доступ к этому API.

Клиент сначала свяжется с API аутентификации и получит токен, а затем передаст этот токен в Business API.

Так как клиент может отправить любой токен бизнес-API. Бизнес должен проверить токен. Он просто не может доверять токену. Поскольку токен генерируется API аутентификации, как бизнес-API будет проверять токен.

Каков стандартный способ проверки токена в таком сценарии, когда API-интерфейс аутентификации и бизнес-API размещаются отдельно?

1 Ответ

0 голосов
/ 04 ноября 2018

Хорошие ссылки

  • Принципы проверки токенов (блог Витторио) - Потрясающая статья, большая часть информации носит общий характер, поэтому применима как к Azure AD, так и без нее, и исходила от очень знающего автора курса

  • Ручная проверка токена доступа JWT в веб-API - Этот сертификат предназначен для проверки выданного токена Azure AD. Имеет полную реализацию кода тоже. Вам не нужно делать именно это, потому что ваша проверка будет зависеть от формата токена / утверждений, которые вы используете, но может предоставить полезную ссылку.

Вы можете посмотреть, как проверка токенов рекомендуется для приложений, защищенных Azure Active Directory, в качестве примера (и, возможно, некоторых других систем), а затем решить, что лучше всего подходит для вашего случая.

Краткое объяснение того, как важен пример Azure AD .. как требуется проверка полученного токена, как и в вашем случае

Когда вы разрабатываете любой веб-API (или веб-приложение), защищенный с помощью Azure Active Directory, и используете аутентификацию на основе маркеров канала-носителя, то, как происходит процесс, очень похоже на то, что вы объяснили выше с двумя API-интерфейсами (просто для понимания цели, для вашей аутентификации). API выполняет то, что должны делать конечные точки токена Azure AD, т. Е. Предоставляет действительный токен.

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

Что проверить?

1. Подпись токена

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

а. Это помогает проверить, что токен действительно был выдан Azure AD (или, в вашем случае, вашим доверенным STS с использованием API аутентификации, о котором вы упомянули).

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

2. Требования к токену

Это будет зависеть от того, какие утверждения / информацию вы отправляете как часть токена (например, если один и тот же API аутентификации выдает токены для нескольких различных API, то для вас может иметь смысл что-то вроде аудитории и издателя. Время действия токена период, использующий что-то вроде nbf и exp ниже, также довольно общий)

Взяв в качестве примера токены, выпущенные Azure AD, можно проверить следующие важные параметры:

  • требование аудитории (aud), чтобы убедиться, что токен был предназначен для передачи вашему приложению
  • не ранее (nbf) и истечения срока действия (exp) заявок, чтобы убедиться, что токен был получен в течение срока его действия
  • претензия эмитента (iss), чтобы убедиться, что этот токен действительно был выдан указанным органом. Обратите внимание, что это второй способ, кроме подписи для той же цели, и обычно и подпись, и проверка эмитента используются вместе. (См. Блог Витторио)
  • nonce , в качестве смягчения атаки при воспроизведении токена
  • претензия арендатора (tid), для проверки арендатора. Это полезно в случае мультитенантных приложений.

Образец токена JWT из Azure AD Фактическое значение: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1N ... (длинная закодированная строка продолжается) Декодированное значение (это можно легко проверить с помощью веб-сайта, например https://jwt.ms или https://jwt.io):

{
  "aud": "https://service.contoso.com/",
  "iss": "https://sts.windows.net/7fe81447-da57-4385-becb-6de57f21477e/",
  "iat": 1388440863,
  "nbf": 1388440863,
  "exp": 1388444763,
  "ver": "1.0",
  "tid": "7fe81447-da57-4385-becb-6de57f21477e",
  "oid": "68389ae2-62fa-4b18-91fe-53dd109d74f5",
  "upn": "frankm@contoso.com",
  "unique_name": "frankm@contoso.com",
  "sub": "deNqIj9IOE9PWJWbHsftXt2EabPVl0Cj8QAmefRLV98",
  "family_name": "Miller",
  "given_name": "Frank",
  "appid": "2d4d11a2-f814-46a7-890a-274a72a7309e",
  "appidacr": "0",
  "scp": "user_impersonation",
  "acr": "1"
}

Как выполнить проверку токена?

Максимально используйте стандартные библиотеки. См. Пример реализации кода Проверка токена доступа JWT вручную в веб-API . Этот метод использует JwtSecurityTokenHandler.ValidateToken метод (JwtSecurityToken) . Ваш случай будет зависеть от формата / реализации вашего токена и т. Д.

...