Потоки AD FS OpenID Connect/OAuth и сценарии приложений

Применимо к службам федерации Active Directory (AD FS) 2019 и более поздних версий

Поток неявного предоставления

Для одностраничных приложений (AngularJS, Ember.js, React.jsи т. д.), AD FS поддерживает неявный поток предоставления OAuth 2.0. Неявный поток описан в спецификации OAuth 2.0. Основное его преимущество заключается в том, что приложения могут получать маркеры от AD FS без обмена учетными данными с внутренним сервером. Этот поток позволяет приложению входить в систему пользователя, поддерживать сеанс и получать токены к другим веб-API в клиентском JavaScript-коде. При использовании неявного потока, в частности, вокруг клиента следует учитывать несколько важных соображений безопасности.

Если вы хотите использовать неявный поток и AD FS для добавления проверки подлинности в приложение JavaScript, выполните общие действия, описанные в следующем разделе.

Схема протокола

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

Запрос ID токена и токена для доступа

Для первоначального входа пользователя в приложение можно отправить запрос проверки подлинности OpenID Connect и получить id_token и маркер доступа из конечной точки AD FS.

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345

На текущем этапе пользователю предлагается ввести учетные данные и завершить аутентификацию. После проверки подлинности пользователя конечная точка авторизации AD FS возвращает ответ на redirect_uri, указанное приложением, используя метод, указанный в параметре response_mode.

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

Успешный ответ при response_mode=fragment and response_type=id_token+token использовании выглядит следующим образом:

// Line breaks for legibility only

GET https://localhost/myapp/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZEstZnl0aEV...
&token_type=Bearer
&expires_in=3599
&scope=openid
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZstZnl0aEV1Q...
&state=12345

Маркеры обновления

Неявное разрешение не предоставляет токены обновления. Срок действия id_tokens и access_tokens истекает через короткий период времени, поэтому приложение должно периодически обновлять эти маркеры. Чтобы обновить любой тип токена, можно выполнить тот же скрытый запрос через iframe, что и в предыдущем разделе, используя параметр prompt=none для управления поведением платформы идентификаций. Если вы хотите получить новый id_token, обязательно используйте response_type=id_token.

Поток предоставления кода авторизации

Вы можете использовать код авторизации OAuth 2.0 в веб-приложениях для получения доступа к защищенным ресурсам, таким как веб-API. Описание потока кода авторизации OAuth 2.0 см. в разделе 4.1 спецификации OAuth 2.0. Он используется для выполнения проверки подлинности и авторизации в большинстве типов приложений, включая веб-приложения и собственные установленные приложения. Поток позволяет приложениям безопасно получать access_tokens, которые можно использовать для доступа к ресурсам, которым доверяет AD FS.

Схема протокола

На обобщенном уровне поток проверки подлинности для нативного приложения выглядит примерно так:

Запрос кода авторизации

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

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&resource=https://webapi.com/
&scope=openid
&state=12345

На текущем этапе пользователю предлагается ввести учетные данные и завершить аутентификацию. После проверки подлинности пользователя AD FS возвращает ответ приложению на указанное redirect_uri, используя метод, указанный в параметре response_mode.

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

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

GET https://adfs.contoso.com/common/oauth2/nativeclient?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345

Запросите маркер доступа

Теперь, когда вы приобрели authorization_code и получили разрешение пользователя, вы можете активировать код для требуемого access_token ресурса. Активация кода путем отправки запроса POST в конечную точку /token:

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com/
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&client_secret=JqQX2PNo9bpM0uEihUPzyrh    // NOTE: Only required for confidential clients (web apps)

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

Успешный ответ токена выглядит следующим образом:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

Используйте токен доступа

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Обновление процесса выдачи токена

Срок действия токенов доступа весьма ограничен, поэтому их нужно обновлять после его истечения, чтобы снова продолжить доступ к ресурсам. Это можно сделать, отправив другой запрос POST в /token конечную точку, на этот раз предоставив refresh_token вместо кода. Токены обновления действительны для всех разрешений, для которых клиент уже получил токены доступа.

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

Хотя маркеры обновления не отзываются при получении новых маркеров доступа, ожидается, что старый маркер обновления следует удалить. Спецификация OAuth 2.0 говорит: "Сервер авторизации МОЖЕТ выдавать новый маркер обновления, в этом случае клиент должен отменить старый маркер обновления и заменить его новым маркером обновления. Сервер авторизации может отозвать старый маркер обновления после выдачи нового маркера обновления клиенту". AD FS выдает маркеры обновления, когда время существования нового маркера обновления превышает предыдущее время существования маркера обновления. Дополнительные сведения о времени существования маркера обновления AD FS см. в параметрах единого входа AD FS.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh      // NOTE: Only required for confidential clients (web apps)

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

Успешный ответ токена выглядит следующим образом:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

Поддержка Proof Key for Code Exchange (PKCE) для OAuth

Общедоступные клиенты OAuth, использующие предоставление кода авторизации, уязвимы для атак перехвата кода авторизации, как описано в RFC 7636. Чтобы устранить эти атаки, по состоянию на Windows Server 2019 AD FS поддерживает ключ подтверждения для обмена кодом (PKCE) для потока предоставления кода авторизации OAuth.

Спецификация поддержки PKCE добавляет дополнительные параметры в запросы на авторизацию и токен доступа OAuth 2.0. На следующей схеме показана структура процесса PKCE, когда клиент обращается к AD FS в Windows Server 2019.

В разделе с меткой A клиент создает и записывает секрет с именем code_verifier и получает преобразованную версию секрета t(code_verifier), которая code_challengeтакже называется . Затем клиент отправляет секрет в запросе авторизации OAuth 2.0 вместе с методом t_m преобразования.

В разделе с меткой B конечная точка авторизации реагирует как обычно, но записывает t(code_verifier) секрет и метод преобразования.

В разделе C клиент отправляет код авторизации в запросе маркера доступа обычным образом, но включает code_verifier секрет, созданный в разделе A.

В разделе с меткой code_verifierD AD FS преобразует секрет и сравнивает его с секретом t(code_verifier) из раздела B. Если их значения не равны, AD FS запрещает доступ.

Выбор нескольких поставщиков проверки подлинности для одной политики правил в Windows Server 2019

AD FS уже поддерживает инициирование дополнительной проверки подлинности на основе политики правил утверждений (RP). Эти политики можно задать для определенной RP или на глобальном уровне. Вы можете задать дополнительную политику проверки подлинности для конкретной RP, открыв PowerShell в качестве администратора и выполнив командлет Set-AdfsRelyingPartyTrust, передав параметр AdditionalAuthenticationRules или AdditionalAuthenticationRulesFile. Чтобы установить его глобально, администратор может использовать командлет Set-AdfsAdditionalAuthenticationRule. Настройка дополнительных политик позволяет использовать несколько поставщиков проверки подлинности для одного приложения.

Правила утверждений предоставляют возможность выбора поставщика проверки подлинности для дополнительной проверки подлинности, которая оказывается полезной в ситуациях, когда клиенты переключаются между поставщиками или требуют отдельного поставщика для определенных приложений. По состоянию на Windows Server 2019 можно использовать правила утверждений, чтобы решить, какой другой поставщик проверки подлинности будет вызываться для дополнительной проверки подлинности. Эта функция полезна в двух сценариях:

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

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

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

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );' 

Чтобы настроить это правило, необходимо выдать утверждение http://schemas.microsoft.com/claims/authnmethodsproviders из других политик проверки подлинности. Значение этого утверждения должно быть переменной Name поставщика аутентификации.

Вы также можете изменить эту конфигурацию правила, чтобы пользователи могли переходить с одного поставщика проверки подлинности на другой. Например, предположим, что вы хотите изменить одну группу, управляемую с помощью многофакторной проверки подлинности (MFA) Microsoft Entra, и одну группу для использования сертификатов в качестве дополнительного поставщика проверки подлинности.

Если вы хотите отслеживать, сколько пользователей регистрируются для проверки подлинности MFA и сертификатов, можно выполнить следующую команду, указав значения, заменяемые значениями, соответствующими вашей организации:

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’ 

Затем можно задать первое приложение, которое вызывается AppA, чтобы использовать MFA в качестве дополнительного поставщика проверки подлинности, выполнив следующую команду:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");' 

Наконец, можно задать второе приложение, вызываемое AppBдля использования сертификатов в качестве дополнительного поставщика проверки подлинности, выполнив следующую команду:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");' 

Администраторы также могут создавать правила для разрешения нескольких дополнительных поставщиков проверки подлинности. В этом случае AD FS показывает выданных поставщиков методов проверки подлинности, и пользователь может выбрать любой из них. Чтобы позволить использовать несколько дополнительных поставщиков аутентификации, они должны выдавать несколько утверждений с помощью значения http://schemas.microsoft.com/claims/authnmethodsproviders.

Если оценка утверждений не возвращает ни одного из поставщиков проверки подлинности, AD FS возвращается к предыдущему состоянию и отображает список всех дополнительных поставщиков проверки подлинности, настроенных администратором в AD FS. Затем пользователь должен вручную выбрать соответствующего поставщика проверки подлинности.

Если предпочтительный поставщик проверки подлинности отсутствует в списке, можно запустить следующий командлет, чтобы просмотреть все поддерживаемые поставщики:

(Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

Значение http://schemas.microsoft.com/claims/authnmethodsproviders для утверждения должно совпадать с одним из имен поставщиков, указанных в списке, который вернул AD FS.

AD FS не поддерживает активацию определенного дополнительного поставщика проверки подлинности, если RP использует политики контроля доступа в AD FS Windows Server 2016. При перемещении приложения из политики управления доступом AD FS копирует соответствующую политику из политики управления доступом в AdditionalAuthenticationRules и IssuanceAuthorizationRules. Если администратор хочет использовать определенный поставщик проверки подлинности, он должен прекратить использование политики управления доступом и вместо этого изменить AdditionalAuthenticationRules.

On-Behalf-Of flow

Поток On-Behalf-Of (OBO) в OAuth 2.0 используется в том случае, когда приложение вызывает службу или веб-API, который, в свою очередь, должен вызывать другую службу или веб-API. Идея состоит в том, чтобы распространить делегированное удостоверение пользователя и разрешения с помощью цепочки запросов. Чтобы служба среднего уровня выполняла аутентифицированные запросы к подчиненной службе, она должна защитить маркер доступа от AD FS от имени пользователя.

Схема протокола

Предположим, что пользователь проходит проверку подлинности в приложении с помощью потока предоставления кода авторизации OAuth 2.0, описанного в предыдущем разделе. На этом этапе приложение содержит маркер доступа для API А (маркер A) с утверждениями пользователя и разрешением на доступ к веб-API среднего уровня (API A). Убедитесь, что клиент запрашивает область user_impersonation в токене. Теперь API A должен выполнить запрос к веб-API нижнего уровня (API B) с проверкой подлинности.

Последующие шаги образуют поток OBO. Эти шаги поясняются на следующей схеме.

1. Клиентское приложение выполняет запрос к API A с токеном A. (При настройке потока OBO в AD FS убедитесь, что выбрана область user_impersonation, и клиенты запрашивают область user_impersonation в запросе.)
2. API A проходит проверку подлинности в конечной точке выдачи маркера AD FS и запрашивает маркер для доступа к API B. (При настройке этого потока в AD FS убедитесь, что API A также зарегистрирован в качестве серверного приложения с идентификатором клиента, который имеет то же значение, что и идентификатор ресурса в API A.).
3. Конечная точка выдачи маркера AD FS проверяет учетные данные API А с использованием маркера А и выдает маркер доступа для API Б (маркер Б).
4. Маркер B задается в заголовке авторизации запроса к API B.
5. API B возвращает данные из защищенного ресурса.

Запрос токена доступа между службами

Чтобы запросить токен доступа, выполните HTTP POST запрос к конечной точке токенов AD FS с параметрами, описанными в следующих разделах.

Первый сценарий: запрос токена доступа с помощью общего секрета

Для совместного секрета запрос на маркер доступа между службами содержит следующие параметры:

Example

Следующий HTTP POST запрашивает токен доступа и токен обновления.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=https://webapi.com/
&client_secret=BYyVnAt56JpLwUcyo47XODd
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIm…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope=openid

Второй сценарий: запрос токена доступа с помощью сертификата

Запрос токена межслужебного доступа, использующего сертификат, содержит следующие параметры:

Обратите внимание, что параметры почти одинаковы. Этот пример аналогичен запросу по общему секрету, за исключением того, что параметр client_secret заменяется двумя параметрами: client_assertion_type и client_assertion.

Example

Следующий HTTP POST запрашивает маркер доступа для веб-API с сертификатом.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id= https://webapi.com/
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNS…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope= openid

Ответ маркера доступа от службы к службе

Ответ успешного выполнения — это ответ JSON OAuth 2.0, имеющий следующие параметры.

Пример успешного ответа

Ниже представлен пример успешного ответа на запрос токена доступа для веб-API.

{
  "token_type": "Bearer",
  "scope": openid,
  "expires_in": 3269,
  "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1t"
  "id_token": "aWRfdG9rZW49ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOa"
  "refresh_token": "OAQABAAAAAABnfiG…"
  "refresh_token_expires_in": 28800,
}

Использование маркера доступа для доступа к защищенному ресурсу

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

Example

GET /v1.0/me HTTP/1.1
Host: https://secondwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQ…

Поток предоставления учетных данных клиента

Учетные данные клиента OAuth 2.0, указанные в RFC 6749 , можно использовать для доступа к размещенным в Интернете ресурсам с помощью удостоверения приложения. Этот тип предоставления разрешения часто используется для взаимодействия между серверами, которое должно выполняться в фоновом режиме без непосредственного взаимодействия с пользователем. Такие типы приложений часто называют управляющими программами или учетными записями служб.

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

Схема протокола

На следующей схеме показан поток предоставления учетных данных клиента.

Запросить токен

Чтобы получить токен с использование предоставления учетных данных клиента, отправьте POST запрос к конечной точке /token AD FS, как показано в следующих разделах.

Первый сценарий: запрос токена доступа с помощью общего секрета

POST /adfs/oauth2/token HTTP/1.1
// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_secret=qWgdYAmab0YSkuL1qKv5bPX
&grant_type=client_credentials

Второй сценарий: запрос токена доступа с помощью сертификата

POST /adfs/oauth2/token HTTP/1.1

// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials

Используйте маркер

Теперь, когда вы приобрели токен, используйте его для выполнения запросов к ресурсу. Когда завершится срок действия маркера, повторите запрос к конечной точке /token, чтобы получить новый маркер доступа.

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Процесс предоставления учетных данных пароля владельца ресурса (не рекомендуется)

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

Схема протокола

На следующей схеме показано представление потока ROPC.

Запрос авторизации

Поток ROPC состоит из одного запроса: он отправляет идентификатор клиента и учетные данные пользователя поставщику удостоверений, а в ответ получает токены. Клиент должен запросить у пользователя адрес электронной почты (UPN) и пароль перед выполнением этого действия. Сразу после успешного выполнения запроса клиент обязан безопасно удалить из памяти учетные данные пользователя. Ни в коем случае нельзя сохранять их.

// Line breaks and spaces are for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope= openid
&username=myusername@contoso.com
&password=SuperS3cret
&grant_type=password

Ответ об успешной аутентификации

Ниже приведен пример успешного ответа на маркер.

{
    "token_type": "Bearer",
    "scope": "openid",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIn...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDR..."
}

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

Поток кода устройства

С помощью предоставления кода устройства пользователи могут входить на устройства с ограниченными возможностями для ввода данных, например на интеллектуальный телевизор, устройство IoT или принтер. Чтобы активировать этот процесс, пользователь должен выполнить вход, посетив веб-страницу на другом устройстве в браузере. После входа пользователя в систему устройство сможет получать токены доступа и токены обновления по мере надобности.

Схема протокола

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

Запрос авторизации устройства

Клиент должен сначала обратиться к серверу проверки подлинности и получить код для устройства и пользователя, который используется для запуска проверки подлинности. Клиент собирает этот запрос из конечной точки /devicecode. В этом запросе клиент также должен добавить разрешения, которые ему требуется получить от пользователя. С момента отправки этого запроса пользователь может выполнить вход только через 15 минут (обычное значение для expires_in), поэтому только выполните этот запрос, если пользователь указал, что он готов войти.

// Line breaks are for legibility only

POST https://adfs.contoso.com/adfs/oauth2/devicecode
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
scope=openid

Ответ авторизации устройства

Успешный ответ — это объект JSON, содержащий необходимые сведения для входа пользователя.

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

После того как клиент получает user_code и verification_uri, он отображает эти сведения пользователю и инструктирует его войти в систему с помощью мобильного телефона или браузера ПК. Кроме того, клиент может использовать QR-код или аналогичный механизм для отображения verification_uri_complete, который устраняет необходимость ввода user_code пользователем. Когда пользователь проходит проверку подлинности на verification_uri, клиент должен опрашивать конечную точку /token для запрошенного токена с помощью device_code.

POST https://adfs.contoso.com /adfs/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type: urn:ietf:params:oauth:grant-type:device_code
client_id: 00001111-aaaa-2222-bbbb-3333cccc4444
device_code: GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8

Ответ об успешной аутентификации

Успешный ответ токена может включать следующие параметры:

Связанный контент

Полный список руководств с пошаговыми инструкциями по использованию соответствующих потоков вы найдете в разделе «Разработка AD FS».