Авторизация доступа к веб-приложениям с помощью OpenID Connect и Azure Active Directory

OpenID Connect — это простой уровень удостоверений, построенный на основе протокола OAuth 2.0. OAuth 2.0 определяет механизмы получения и использования маркеров доступа для доступа к защищенным ресурсам, но они не определяют стандартные методы для предоставления сведений об удостоверениях. OpenID Connect реализует проверку подлинности в качестве расширения для процесса авторизации OAuth 2.0. Он содержит сведения о конечном пользователе в виде id_token, который подтверждает личность пользователя и предоставляет основную информацию профиля пользователя.

OpenID Connect — это наша рекомендация, если вы создаете веб-приложение, размещенное на сервере, и обращаетесь через браузер.

Регистрация приложения в клиенте AD

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

1. Войдите на портал Azure.

2. Выберите арендатора Azure AD, выбрав свою учетную запись в правом верхнем углу страницы, затем перейдите к навигации "Переключить каталог" и выберите соответствующего арендатора.

   • Пропустите этот шаг, если у вас есть только один клиент Azure AD в учетной записи или вы уже выбрали соответствующий клиент Azure AD.

3. На портале Azure найдите и выберите Azure Active Directory.

4. В левом меню Azure Active Directory выберите Регистрация приложений, а затем выберите Новая регистрация.

5. Следуйте инструкциям и создайте новое приложение. Для этого руководства не имеет значения, будет ли это веб-приложение или общедоступное клиентское приложение (мобильное или настольное &), но если вы хотите получить конкретные примеры для веб-приложений или общедоступных клиентских приложений, ознакомьтесь с нашими быстрыми стартами .

   • Имя служит названием вашего приложения и описывает его конечным пользователям.
   • В разделе Поддерживаемые типы учетных записей выберите Accounts in any organizational directory and personal Microsoft accounts (Учетные записи в любом каталоге организации и личные учетные записи Майкрософт).
   • Укажите URI перенаправления. Для веб-приложений это базовый URL-адрес приложения, в котором пользователи могут войти. Например, http://localhost:12345. Для общедоступного клиента (мобильных и настольных) Azure AD использует его для возврата ответов с токенами. Введите значение, определенное для приложения. Например, http://MyFirstAADApp.

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

7. Чтобы найти приложение на портале Azure, выберите Регистрация приложений, а затем выберите Просмотр всех приложений.

Поток проверки подлинности при использовании OpenID Connect

Самый простой поток входа содержит следующие шаги. Каждый из них подробно описан ниже.

Документ метаданных OpenID Connect

OpenID Connect описывает документ метаданных, содержащий большую часть сведений, необходимых для выполнения входа в приложение. Сюда входят такие сведения, как ИСПОЛЬЗУЕМЫЕ URL-адреса и расположение открытых ключей подписывания службы. В документе метаданных OpenID Connect можно найти следующее:

https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration

Метаданные — это простой документ нотации объектов JavaScript (JSON). Пример см. в следующем фрагменте кода. Содержимое фрагмента полностью описано в спецификации OpenID Connect. Обратите внимание, что предоставление идентификатора клиента вместо common для {tenant} выше приведет к тому, что URI, специфичные для клиента, будут в возвращаемом объекте JSON.

{
    "authorization_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/authorize",
    "token_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/token",
    "token_endpoint_auth_methods_supported":
    [
        "client_secret_post",
        "private_key_jwt",
        "client_secret_basic"
    ],
    "jwks_uri": "https://login.microsoftonline.com/common/discovery/keys"
    "userinfo_endpoint":"https://login.microsoftonline.com/{tenant}/openid/userinfo",
    ...
}

Если приложение содержит пользовательские ключи подписывания в результате использования функции сопоставления утверждений , необходимо добавить параметр запроса appid, содержащий идентификатор приложения, чтобы получить jwks_uri, содержащий сведения о ключе подписи приложения. Например, https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e содержит jwks_uri из https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e.

Отправьте запрос на вход

Когда веб-приложение должно пройти проверку подлинности пользователя, он должен направить пользователя в конечную точку /authorize. Этот запрос аналогичен первому этапу потока кода авторизации OAuth 2.0 с несколькими важными различиями:

• Запрос должен содержать область openid в параметре scope.
• Параметр response_type должен содержать id_token.
• Запрос должен содержать параметр nonce.

Таким образом, пример запроса будет выглядеть следующим образом:

// Line breaks for legibility only

GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%3a12345
&response_mode=form_post
&scope=openid
&state=12345
&nonce=7362CAEA-9CA5-4B43-9BA3-34D7C303EBA7

На текущем этапе пользователю предлагается ввести учетные данные и завершить аутентификацию.

Пример ответа

Пример ответа, отправленный в redirect_uri, указанный в запросе на вход после проверки подлинности пользователя, может выглядеть следующим образом:

POST / HTTP/1.1
Host: localhost:12345
Content-Type: application/x-www-form-urlencoded

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345

Ответ на ошибку

Сообщения об ошибках также можно отправлять на redirect_uri , чтобы приложение обрабатывало их должным образом:

POST / HTTP/1.1
Host: localhost:12345
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication

Коды ошибок на конечной точке авторизации

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

Подтвердите id_token

Просто получение id_token недостаточно для аутентификации пользователя; необходимо проверить подпись и удостовериться в утверждениях в id_token в соответствии с требованиями вашего приложения. Конечная точка Azure AD использует веб-маркеры JSON (JWTs) и криптографию открытого ключа для подписывания маркеров и проверки их допустимости.

Вы можете проверить id_token в клиентском коде, но распространенная практика заключается в отправке id_token на внутренний сервер и выполнить проверку там.

Вы также можете проверить дополнительные утверждения в зависимости от вашего сценария. Ниже приведены некоторые распространенные проверки:

• Обеспечение регистрации пользователя или организации для приложения.
• Обеспечение надлежащей авторизации и привилегий пользователя с помощью заявок wids или roles.
• Обеспечение определенного уровня надежности аутентификации, например многофакторной аутентификации.

После проверки id_tokenможно начать сеанс с пользователем и использовать утверждения в id_token для получения сведений о пользователе в приложении. Эти сведения можно использовать для отображения, ведения записей, персонализации и т. д. Дополнительные сведения о id_tokens и требованиях см. в AAD id_tokens.

Отправка запроса на выход

Если вы хотите выйти из приложения, недостаточно очистить файлы cookie вашего приложения или завершить сеанс с пользователем. Вы также должны перенаправить пользователя на end_session_endpoint для выхода. Если это не удалось сделать, пользователь сможет повторно выполнить проверку подлинности в приложении без ввода учетных данных, так как у него будет действительный сеанс единого входа с конечной точкой Azure AD.

Вы можете просто перенаправить пользователя на end_session_endpoint, перечисленного в документе метаданных OpenID Connect.

GET https://login.microsoftonline.com/common/oauth2/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F

Единый выход из системы

При перенаправлении пользователя в end_session_endpointAzure AD очищает сеанс пользователя из браузера. Однако пользователь может войти в другие приложения, использующие Azure AD для проверки подлинности. Чтобы эти приложения могли одновременно вывести пользователя из системы, Azure AD отправляет HTTP-запрос GET на LogoutUrl зарегистрированных всех приложений, в которые в настоящий момент вошёл пользователь. Приложения должны реагировать на этот запрос, очищая любой сеанс, который идентифицирует пользователя и возвращает ответ 200. Если вы хотите поддерживать функцию единого выхода в приложении, необходимо реализовать соответствующий LogoutUrl в коде вашего приложения. Вы можете задать LogoutUrl на портале Azure:

1. Войдите на портал Azure.
2. Выберите Active Directory, щелкнув свою учетную запись в правом верхнем углу страницы.
3. На панели навигации слева выберите Azure Active Directory, а затем выберите регистрации приложений и выберите приложение.
4. Щелкните параметры, затем Свойства и найдите текстовое поле URL-адрес выхода.

Получение токена

Многие веб-приложения должны не только авторизовать пользователя, но и получить доступ к веб-службе от его имени с использованием OAuth. Этот сценарий сочетает использование OpenID Connect для аутентификации пользователей и одновременное получение authorization_code, который можно использовать для получения access_tokens с помощью потока авторизации OAuth .

Получите токены доступа

Чтобы получить токены доступа, необходимо изменить вышеописанный запрос на вход.

// Line breaks for legibility only

GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e        // Your registered Application ID
&response_type=id_token+code
&redirect_uri=http%3A%2F%2Flocalhost%3a12345          // Your registered Redirect Uri, url encoded
&response_mode=form_post                              // `form_post' or 'fragment'
&scope=openid
&resource=https%3A%2F%2Fservice.contoso.com%2F        // The identifier of the protected resource (web API) that your application needs access to
&state=12345                                          // Any value, provided by your app
&nonce=678910                                         // Any value, provided by your app

Включив в запрос области разрешений и используя response_type=code+id_token, конечная точка authorize гарантирует, что пользователь дал согласие на разрешения, указанные в параметре запроса scope, и возвращает код авторизации приложения для обмена маркером доступа.

Успешный ответ

Успешный ответ, отправленный в redirect_uri с помощью response_mode=form_post, выглядит следующим образом:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...&state=12345

Ответ на ошибку

Сообщения об ошибках также можно отправлять на redirect_uri , чтобы приложение обрабатывало их должным образом:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication

Для описания возможных кодов ошибок и их рекомендуемых действий клиента см. в разделе "Коды ошибок конечной точки авторизации".

Получив code и id_tokenавторизации, вы можете войти в систему и получить токены доступа от их имени. Чтобы авторизовать пользователя, необходимо проверить id_token точно так же, как описано выше. Чтобы получить маркеры доступа, можно выполнить действия, описанные в разделе "Использование кода авторизации для запроса маркера доступа" нашей документации по потоку кода OAuth .

Дальнейшие действия

• Дополнительные сведения о маркерах доступа .
• Получите дополнительные сведения о ,id_token и.