Прежде всего, поздравляю вас с хорошими результатами.
Теперь переходим к беспокойству о том, что вы находитесь ...
- Кодирует ли токен доступа всю упомянутую мной информацию?(appid, scope, resource, userid)
Вы достаточно закрыты, но для большей ясности Resource и Scope одинаковы.Как известно, у Azure Active Directory есть две версии V1.0 и версия V.20
Resource в V1.0, который заменили на V2.0, так как Scope оба определяют домен доступа пользователя.
Сейчасдавайте выясним, какой токен на самом деле содержит
В соответствии с вашим вопросом, в Azure Active Directory поддерживается множество протоколов OAuth 2.0 , поэтому каждый протокол имеет свою работу.Я объясняю два для вас.
Azure Active Directory v2.0 и учетные данные владельца ресурса OAuth 2.0
ROPC TokenПример POSTMAN
Давайте рассмотрим пример токена с использованием протокола ROPC.См. Снимок экрана ниже =>
Если вы посмотрите на требования по токену на https://jwt.io/, вы получите ответ
см. Снимок экрана ниже:
Здесь в этом протоколе мы имеем
appId, UserId, Ресурс / Область и много другой информации, отмеченной на картинке.
Но все остальные протоколы токенов не содержат такой же информации.Вы также можете проверить OpenID Connect утверждения токена протокола.
Зачем нам нужно снова проверять входящую область? OAuth был разработан для случаев, когда приложению X требуется доступ к ресурсам (например, «моя информация» или «мой адрес электронной почты "или" мой календарь "), контролируемый Приложением Y и принадлежащий Пользователю A - Пользователь A может захотеть предоставить доступ к этим ресурсам в Приложении Y, но он не хочет предоставлять Приложению X свои действительные учетные данные имени пользователя / пароля,Таким образом, токен доступа используется в качестве альтернативных учетных данных для ресурса в Приложении Y. Токены доступа могут быть отозваны независимо от учетных данных имени пользователя / пароля и, в идеале, ограничены для предоставления доступа только к определенным ресурсам.
ИспользованиеOAuth 2 для аутентификации перегружает эту модель способами, которые могут быть рискованными.Посмотрите на приведенный выше пример и представьте, что он используется для аутентификации.Если Приложение X использует этот токен доступа для аутентификации, то он берет токен, который предоставляет доступ к ресурсам в Приложении Y, и использует его для предоставления доступа к своим собственным ресурсам.Возможно, это расщепляет волоски, потому что важно то, что мы знаем, что действие по предоставлению токена доступа через OAuth 2 подразумевает, что пользователь успешно прошел аутентификацию.
Проблема в том, что токен доступа ничего не говорит о том, для какого приложения аутентифицировался конечный пользователь.Так что же произойдет, если приложение Z также имеет токен доступа для ресурсов пользователя A в приложении Y?Если приложение Z может заставить приложение X использовать этот токен доступа, то оно имеет доступ к ресурсам пользователя A в приложении X. Это плохо.Пользователь А, возможно, доверял Приложению Z для доступа к своим ресурсам в Приложении Y, но Пользователь А, безусловно, никогда не давал согласия Приложению Z на доступ к его ресурсам в Приложении X. Для более подробного объяснения вы можете сослаться здесь
Другая причина
Судя по моему опыту, но я не совсем уверен в том, что мы часто обновляем разрешение нашего приложения и объем доступа, если он не проверяет всегда, мы не сможемдоступ к нашим последним учетным данным также.Вы также можете сослаться на хорошую ветку здесь