Headless Identity API: Поток входа без пароля для личных клиентов

Конечный пользователь вводит свой электронный адрес или номер телефона для входа

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

Ваше приложение находит имя пользователя

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

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

Ваше приложение отправляет запрос в API входа без пароля

В обозревателе приложение отправляет запрос POST без заголовка в конечную точку входа без пароля (services/auth/headless/init/passwordless/login) на сайте Experience Cloud.

Добавьте заголовок для проверки подлинности запроса.

Добавьте следующие параметры в текст запроса.

Ниже указан пример запроса API входа без пароля. В данном примере проверка подлинности обязательна, а reCAPTCHA нет. Этот запрос для внедрения, не использующего средство обнаружения пользователей без заголовка.

POST /services/auth/headless/init/passwordless/login? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com
Authorization: Bearer <access token>
{
 "verificationmethod": "email",
"username": "janice.edwards@example.com",
"emailtemplate": "unfiled$public/SalesNewCustomerEmail"
}

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

POST /services/auth/headless/init/passwordless/login? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com
Authorization: Bearer <access token>
{
 "verificationmethod": "email",
"login_hint": "<user identifier such as email address, phone number, order number>",
"emailtemplate": "unfiled$public/SalesNewCustomerEmail"
}

(Дополнительно) Обработчик обнаружения без заголовка пользователя находит пользователя

Если вы используете средство обработки обнаружения пользователей без заголовка, средство обработки извлекает параметр login_hint и находит связанного пользователя. Обработчик подтверждает, что электронный адрес или номер телефона пользователя проверен.

Пример средства обработки см. в разделе Auth.HeadlessUserDiscoveryHandler Справочного руководства Apex.

Salesforce возвращает идентификатор запроса в приложение

Если запрос успешен, Salesforce отправляет обратно сообщение об успешном выполнении, содержащее identifier запроса, что важно позже в потоке при обмене на маркер доступа. Ниже указан пример сообщения об успешном выполнении.

{
"status": "success",
"email": "jedwards@example.com",
"identifier": "0RXXXXXXXX"
}

Salesforce отправляет ОТП пользователю

Сразу же после отправки Salesforce идентификатора запроса в приложение пользователь получает сообщение эл. почты или SMS-сообщение с OTP.

Ваше приложение отображает форму проверки

В вашем приложении вы нативно отображаете форму проверки, где пользователь может ввести свой ОТП.

Конечный пользователь вводит OTP

Конечный пользователь получает ОТП по электронной почте или посредством текстового сообщения и вводит его в форму проверки в вашем приложении.

Ваше приложение создает параметры для PKCE

Если вы используете расширение PKCE (что мы настоятельно рекомендуем), ваше приложение создает параметры code_verifier и code_challenge.

Спецификация PKCE, определенная в RFC 7636, также содержит дополнительный параметр code_challenge_method, который можно отправить в запрос авторизации. Salesforce игнорирует любое значение, отправленное в этом параметре, и по умолчанию использует значение SHA256.

Ваше приложение отправляет запрос в конечную точку авторизации

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

Добавьте следующие заголовки в запрос авторизации.

Добавьте следующие параметры в текст запроса.

Ниже указан пример запроса к конечной точке авторизации. Данный пример включает PKCE.

POST /services/oauth2/authorize? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com
Auth-Request-Type: passwordless-login
Auth-Verification-Type: email
Authorization: Basic <base64-encoded identifier:OTP

response_type=code_credentials&
client_id=***********&
redirect_uri=https://www.MyDomainName.my.site.com/services/apexrest/code/exchange&
code_challenge=********

Salesforce проверяет запрос и возвращает переадресацию 302

Когда запрос достигает конечной точки авторизации, Salesforce проверяет идентификатор запроса и ОТП. Salesforce потом возвращает переадресацию HTTP 302 на готовый URL-адрес, содержащий код авторизации. Если поток происходит в обозревателе, переадресация 302 обрабатывается в обозревателе, и Salesforce автоматически отправляет ответ переадресации на URL-адрес переадресации, являющийся конечной точкой серверного обратного вызова. Ниже указан пример предварительно настроенного URL-адреса.

https://www.MyDomainName.my.site.com/services/apexrest/code/exchange?code=aPrxC1*******
&sfdc_community_url=https%3A%2F%2FMyDomainName.my.site.com&sfdc_community_id=0DBxxxxxxxxxxxx

Серверное средство обработки обратного вызова извлекает код и выполняет обмен кодами

Серверное средство обработки обратного вызова извлекает код авторизации и другие параметры из переадресации 302. Потом он запускает обмен кодами, отправляя запрос POST без заголовка в конечную точку маркера.

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

Ниже указан пример запроса маркера. Данный пример использует PKCE.

POST services/oauth2/token? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com

code=********&
client_id=**********&
client_secret=*********&
redirect_uri=https://www.MyDomainName.my.site.com/services/apexrest/code/exchange&
grant_type=authorization_code&
code_verifier=*******

Salesforce предоставляет маркер доступа

После проверки регистрационных данных приложения. Salesforce возвращает маркер доступа серверному средству обработки обратного вызова. Ниже указан пример ответа на маркер доступа в формате JSON.

{
"access_token":"*******************",
"sfdc_community_url":"https://MyDomainName.my.site.com",
"sfdc_community_id":"0DBxxxxxxxxxxxx",
"signature":"ts6wm/svX3jXlCGR4uu+SbA04M6qhD1SAgVTEwZ59P4=",
"scope":"openid api",
"id_token":"XXXXXX",
"instance_url":"https://yourInstance.salesforce.com",
"id":"https://yourInstance.salesforce.com/id/00Dxxxxxxxxxxxx/005xxxxxxxxxxxx",
"token_type":"Bearer",
"issued_at":"1667600739962"
}

Ответ маркера доступа содержит следующие параметры.

Серверное средство обработки обратного вызова обрабатывает ответ маркера

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

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

{
"success":true,
"state":"https://MyExperienceCloudSite.my.site.com/",
"errMsg":"null",
"access_token":"00*******"
}

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

Приложение получает ответ маркера доступа и создает сеанс пользователя.

Пользователь вошел в систему и выполняет действие в приложении

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

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

Приложение выполняет проверенный вызов конечной точки Salesforce

Чтобы получить доступ к данным Salesforce пользователя, приложение использует маркер доступа для осуществления проверенного вызова защищенной конечной точки Salesforce, например, Salesforce API.

Доступ пользователя к данным Salesforce

Пользователь теперь имеет доступ к защищенным данным Salesforce в вашем приложении. Например, они могут просмотреть журнал заказа. С точки зрения пользователя, весь процесс от входа до доступа к данным происходил без необходимости выхода из приложения.