Подход, который вы используете в настоящее время, будет работать только в одном сценарии арендатора, т. Е. Автоматическая проверка арендатора путем настройки IssuerURL работает только в одном сценарии арендатора.
В случае мультитенантных приложений, приложение отвечает за хранение и проверку всех возможных эмитентов. Это по проекту , и точное руководство по этой теме от Microsoft доступно здесь:
Работа с удостоверениями на основе утверждений в Azure AD: проверка эмитента
Для приложения с одним арендатором вы можете просто проверить, что эмитент
ваш собственный арендатор. На самом деле, промежуточное ПО OIDC делает это автоматически
по умолчанию. В мультитенантном приложении необходимо учитывать несколько
эмитенты, соответствующие различным арендаторам. Вот общий
подход к использованию:
- В параметрах промежуточного программного обеспечения OIDC установите для ValidateIssuer значение false. Это отключает автоматическую проверку.
- Когда арендатор регистрируется, сохраните арендатора и эмитента в своей пользовательской базе данных.
- Всякий раз, когда пользователь входит в систему, ищите издателя в базе данных. Если издатель не найден, это означает, что арендатор не зарегистрировался. Вы
можете перенаправить их на страницу регистрации.
- Вы также можете занести в черный список определенных арендаторов; например, для клиентов, которые не оплатили свою подписку.
Так, в случае веб-приложения на основе .NET код в вашем классе запуска изменится на что-то вроде этого ... обратите внимание на new TokenValidationParameters {ValidateIssuer = false}
Аутентификация с использованием Azure AD и OpenID Connect
app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions {
ClientId = configOptions.AzureAd.ClientId,
ClientSecret = configOptions.AzureAd.ClientSecret, // for code flow
Authority = Constants.AuthEndpointPrefix,
ResponseType = OpenIdConnectResponseType.CodeIdToken,
PostLogoutRedirectUri = configOptions.AzureAd.PostLogoutRedirectUri,
SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme,
TokenValidationParameters = new TokenValidationParameters { ValidateIssuer = false },
Events = new SurveyAuthenticationEvents(configOptions.AzureAd, loggerFactory),
});
После того, как вы отключили издателя Validate, вам нужно будет самостоятельно выполнить проверку. Вот пример с некоторыми рекомендациями о том, как выполнить эту проверку самостоятельно
Обновление кода для обработки нескольких значений эмитента
Перед тем, как разрешить вызов, вам, по крайней мере, нужно будет проверить заявление "tid", в котором записан идентификатор клиента Azure AD, по собственному списку действительных идентификаторов клиента.
Когда одно приложение-арендатор проверяет токен, оно проверяет
подпись токена под ключами подписи из метаданных
документ, и убедитесь, что значение эмитента в токене совпадает с
это было найдено в документе метаданных.
Поскольку конечная точка / common не соответствует арендатору и не является
эмитент, когда вы проверяете значение эмитента в метаданных для / общие
он имеет шаблонный URL вместо фактического значения:
https://sts.windows.net/{tenantid}/
Поэтому мультитенантное приложение не может проверять токены только
сопоставление значения эмитента в метаданных со значением эмитента в
маркер. Мультитенантному приложению нужна логика, чтобы решить, какой эмитент
значения действительны, а какие нет, на основе части идентификатора арендатора
стоимость эмитента.
Например, если мультитенантное приложение разрешает вход только с
конкретные арендаторы, которые подписались на их услуги, то он должен
проверьте значение эмитента или значение требования tid в токене, чтобы
убедитесь, что арендатор находится в их списке подписчиков. Если
мультитенантное приложение работает только с физическими лицами и не
любые решения о доступе на основе арендаторов, то он может игнорировать эмитента
значение в целом.
(РЕДАКТИРОВАТЬ) Подробнее о проверке токенов
Я пытаюсь ответить на ваши вопросы из комментариев здесь.
- Вот пример кода, который выполняет ручную проверку токенов JWT.
Проверка токена доступа JWT вручную в веб-API
Полезный отрывок.
Проверка претензий, когда приложение получает токен доступа
после входа в систему пользователь также должен выполнить несколько проверок
претензии в токене доступа. Эти проверки включают, но не
ограничено:
утверждение аудитории, чтобы убедиться, что идентификационный токен был предназначен для
к вашему заявлению не ранее, а «истечение срока» претензий, для проверки
что идентификатор токена еще не истек претензии эмитента, чтобы убедиться, что
токен был выдан вашему приложению одноразовым номером конечной точки v2.0 как токен
Защита от повторной атаки Рекомендуется использовать стандартную библиотеку.
такие методы, как JwtSecurityTokenHandler.ValidateToken Method
(JwtSecurityToken), чтобы сделать большую часть вышеупомянутой тяжелой работы. Вы
может дополнительно расширить процесс проверки путем принятия решений на основе
претензии полученные в токене. Например, мультитенантные приложения
может продлить стандартную проверку путем проверки значения TID
требование (ID арендатора) против набора предварительно выбранных арендаторов, чтобы гарантировать, что они
только жетон чести от арендаторов по их выбору.
- Пример токена доступа, просто для понимания: Access Token и Id_token - это простые JSON-токены (JWT) в кодировке base64. Вы можете расшифровать их, чтобы найти претензии, а затем подтвердить их. Я делюсь примером, который имеет код, чтобы сделать это. Перед этим приведен пример токена доступа от одного из документов Microsoft. Я просто взял один, например, из здесь
Фактическое значение: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1N ... (длинная закодированная строка продолжается)
Декодированное значение (вы можете легко проверить это, используя веб-сайт, например 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"
}
Как видите, декодированное значение имеет много утверждений, в том числе "tid", которые вы собираетесь проверить.
Надеюсь, это поможет!