Loading
Идентификация пользователей и управление доступом
Headless Identity API: Код авторизации и поток регистрационных данных для общедоступных клиентов

Headless Identity API: Код авторизации и поток регистрационных данных для общедоступных клиентов

Для общедоступных клиентов, например, одностраничных приложений или мобильных приложений, можно настроить вход без заголовка для клиентов и партнеров посредством кода авторизации и потока регистрационных данных. Этот поток создан на основе типа предоставления кода авторизации OAuth 2.0. С помощью кода авторизации и потока регистрационных данных вы управляете взаимодействием входа переднего края в стороннем приложении. Вы вызываете Salesforce Headless Login API посредством сайта Experience Cloud для выполнения фоновой работы по проверке подлинности пользователей и предоставлению доступа к защищенным ресурсам Salesforce. С помощью отдельных фронтальных и фоновых процессов пользователи могут входить и открывать данные Salesforce, не выходя из приложения. В приложениях с одной страницей вы используете конечную точку серверного обратного вызова для извлечения кода авторизации и выполняете обмен кодами из обозревателя посредством клиентского JavaScript.

Требуемые версии

Доступно в версиях: Salesforce Classic и Lightning Experience
Доступно в версиях: Enterprise Edition, Unlimited Edition и Developer Edition
Предупреждение!
Предупреждение! В целях безопасности настоятельно рекомендуем всегда использовать вариант клиентского сервера этого потока при любой возможности. Вариант клиент-сервер предоставляет дополнительную защиту секрета пользователя во время обмена кодом. Дополнительную информацию см. в разделе Headless Identity API: Код авторизации и поток регистрационных данных для частных клиентов.
Примечание
Примечание Здесь стороннее приложение обозначает любое приложение за пределами Salesforce.

Это содержимое справки описывает, как настроить поток и как он работает. Чтобы настроить комплексный пример внедрения, см. Руководство по внедрению функции беспроводной идентификации.

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

Поскольку вы управляете Salesforce Customer Identity посредством сайтов Experience Cloud, вы можете настроить код авторизации и поток регистрационных данных только для клиентов и партнеров, использующих субдомен сайта Experience Cloud, например, https://MyExperienceCloudSite.my.site.com. Этот поток нельзя настроить для сотрудников, входящих на платформу Salesforce посредством login.salesforce.com или URL-адреса входа в «Мой домен» организации, или для сотрудников, входящих на сайты Experience Cloud.

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

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

Ниже указан упрощенный обзор потока в действии.

Диаграмма с кодом авторизации и потоком регистрационных данных для одностраничных приложений
  • Пользователь переходит в настраиваемое приложение, где форма входа нативно отображается в приложении, и вводит имя пользователя и пароль. Или, если вы используете обнаружение пользователя без заголовка, они вводят идентификатор, например, электронный адрес, номер телефона или номер заказа, вместе с паролем.
  • Если вы используете расширение «Ключ подтверждения для обмена кодами (PKCE)», приложение создает значения для проверки кода авторизации. Если вы не используете PKCE, поток пропускает этот этап. Мы настоятельно рекомендуем всегда использовать PKCE при внедрении этого потока для приложений на одной странице.
  • В обозревателе настраиваемое приложение отправляет запрос авторизации без заголовка в конечную точку авторизации Salesforce Headless Login API на сайте Experience Cloud.
  • Если вы используете обнаружение пользователя без заголовка, средство обработки Apex находит пользователя на основе идентификатора, использованного для входа. Если регистрационные данные пользователя действительны и у пользователя есть проверенный адрес эл. почты или номер телефона, вход будет продолжен.
  • Salesforce Headless Login API проверяет регистрационные данные пользователя и возвращает переадресацию HTTP 302 на готовый URL-адрес, содержащий код авторизации. Salesforce потом автоматически отправляет ответ переадресации на URL-адрес переадресации, который указывает на серверное средство обработки обратного вызова.
  • Серверное средство обработки обратного вызова извлекает код авторизации из переадресации 302 и возвращает его приложению.
  • Клиентский JavaScript получает параметры URL-адреса переадресации и инициирует обмен кода посредством запроса POST в конечную точку маркера.
  • Salesforce Headless Login API проверяет запрос и возвращает ответ маркера доступа приложению.
  • Клиентский JavaScript в приложении обрабатывает маркер доступа и создает сеанс пользователя.
  • Пользователь вошел в систему и выполняет действие в настраиваемом приложении, инициирующее запрос данных Salesforce. Например, они нажимают кнопку для доступа к журналу бронирования путешествий, который хранится на сайте Salesforce Experience Cloud.
  • Ваше настраиваемое приложение отправляет проверенный запрос в защищенную конечную точку Salesforce, например, Salesforce API.
  • Пользователь теперь имеет доступ к защищенным данным в настраиваемом приложении. Например, они могут просмотреть журнал бронирования.

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

var clientId = "<Connected App Client ID>";
var baseURL = "<Experience Cloud Domain>";
var redirectURL = "<Experience Cloud Domain>/services/apexrest/code/extraction"
      
// Performs the code exchange
function doCodeExchange(authorizeResponse) {
   //Perform Code Exchange
   //Get Access Token
   var client = new XMLHttpRequest();
   client.open("POST", authorizeResponse.sfdc_community_url + "/services/oauth2/token", true);
   client.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
   client.send("code=" + authorizeResponse.code + "&grant_type=authorization_code&client_id=" + clientId + "&redirect_uri=" + redirectURL);
   client.onreadystatechange = function() {
       if(this.readyState == 3) {
           response = JSON.parse(client.response);
           getUserInfo(response.access_token, response.sfdc_community_url)
       }
   }
}

// Gets User Info
function getUserInfo(accessToken, userInfoBaseURL) {
   var client = new XMLHttpRequest();
   client.open("GET", userInfoBaseURL + "/services/oauth2/userinfo", true);
   client.setRequestHeader("Content-Type", "application/json");
   client.setRequestHeader("Authorization", "Bearer " + accessToken);
   client.send();
   client.onreadystatechange = function() {
       if(this.readyState == 3) {
           response = JSON.parse(client.response);
           response.access_token = accessToken;
           document.getElementById("json").textContent = JSON.stringify(response, undefined, 2);
           document.getElementById("results").style.display="block";
       }
   }
}

//Starts the Login Process
function startLogin() {
   var username = document.getElementById('user_name').value;
   var password = document.getElementById('password').value;
  
   var encodedUNP = btoa(username + ':' + password);
   var client = new XMLHttpRequest();
  
   client.open("POST", baseURL + "/services/oauth2/authorize", true);
   client.setRequestHeader("Auth-Request-Type", "Named-User");
   client.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
   client.setRequestHeader("Authorization", "Basic " + encodedUNP);
   client.send("response_type=code_credentials&client_id=" + clientId + "&redirect_uri=" + redirectURL);
   client.onreadystatechange = function() {
       if(this.readyState == 3) {
           response = JSON.parse(client.response);
           doCodeExchange(response);
       }
   }
   return false;
}    

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

@RestResource(urlMapping='/code/extraction')
global class CodeExtractorAPI {
  
   @HttpGet
   global static CodeResponse doGet() {
       RestRequest req = RestContext.request;
       RestResponse res = RestContext.response;
       try {
           res.statusCode = 200;
           return new CodeResponse(req.params.get('code'), req.params.get('sfdc_community_url'), req.params.get('sfdc_community_id'), req.params.get('state'));
       } catch (Exception e) {
           res.statusCode = 500;
           return new CodeResponse('Could not parse auth code redirect URI');
       }
      
   }
  
   // Response Wrapper
   global class CodeResponse {
       String code;
       String sfdc_community_url;
       String sfdc_community_id;
       String state;
       Boolean success;
       String errMsg;
      
       public CodeResponse(String code, String sfdc_community_url, String sfdc_community_id, String state) {
           this.code = code;
           this.sfdc_community_url = sfdc_community_url;
           this.sfdc_community_id = sfdc_community_id;
           this.state = state;
           this.success = true;
       }
      
        public CodeResponse(String errMsg) {
           this.success = false;
           this.errMsg = this.errMsg;
       }       
   }
}

Ниже указана подробная разбивка этого потока.

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

Пользователь открывает стороннее приложение для входа. В приложении форма входа отображает поля имени пользователя и пароля и кнопку входа. Salesforce не предоставляет эту форму входа. Это зависит от тебя. Пользователь вводит имя пользователя и пароль и нажимает кнопку входа.

Стороннее приложение создает значения code_verifier и code_challenge (дополнительно)

Если вы используете расширение «Ключ подтверждения для обмена кодами (PKCE)», приложение создает значения, используемые для проверки кода авторизации.

Ваш поток содержит этот этап, только если вы используете расширение «Ключ подтверждения для обмена кодами (PKCE)». В качестве рекомендации по безопасности настоятельно рекомендуем использовать расширение PKCE при внедрении кода авторизации и потока регистрационных данных, особенно для приложений на одной странице. Дополнительную информацию о PKCE см. в спецификации RFC 7636: Ключ подтверждения для обмена кодами общедоступными клиентами OAuth, предоставленной инженерно-технической группой (IETF).

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

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

В обозревателе настраиваемое приложение отправляет запрос кода авторизации без заголовка в конечную точку авторизации Salesforce Headless Login API посредством JavaScript. Если вы не используете обнаружение пользователя без заголовка, используйте метод GET или POST для этого запроса. При использовании функции обнаружения пользователей без заголовка поддерживаются только запросы POST.

В этом фрагменте клиентского JavaScript запрос авторизации отправляется как часть функции startLogin. После извлечения регистрационных данных пользователя функция создает и отправляет запрос POST, включительно с URL-адресом переадресации, указывающим на серверное средство обработки обратного вызова.

function startLogin() {
   var username = document.getElementById('user_name').value;
   var password = document.getElementById('password').value;
   var encodedUNP = btoa(username + ':' + password);
   var client = new XMLHttpRequest();
   client.open("POST", baseURL + "/services/oauth2/authorize", true);
   client.setRequestHeader("Auth-Request-Type", "Named-User");
   client.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
   client.setRequestHeader("Authorization", "Basic " + encodedUNP);
   client.send("response_type=code_credentials&client_id=" + clientId + "&redirect_uri=" + redirectURL);
   client.onreadystatechange = function() {
       if(this.readyState == 3) {
           console.log("here");
           console.log(client.response);
           response = JSON.parse(client.response);
           if (response.success) {
               getUserInfo(response.access_token, baseURL);
           }
       }
   }
   return false;
}    

Для запросов GET и POST необходимо добавить Auth-Request-Type: Named-User заголовка.

В зависимости от используемого метода и конфигурации приложения внешнего клиента или связанного приложения, иногда требуется добавить заголовок авторизации типа «Базовый», содержащий регистрационные данные пользователя. Если вы используете запрос GET, необходимо отправить регистрационные данные - имя пользователя и пароль, добавленные друг к другу и зашифрованные в Base64 - в заголовке авторизации. Ниже указан пример запроса GET.

GET /services/oauth2/authorize? HTTP 1.1
Host: MyDomainName.my.site.com
Auth-Request-Type: Named-User
Authorization: Basic <encoded username:password>

response_type=code_credentials&
redirect_uri=https://www.MyExperienceCloudSite.my.site.com/services/apexrest/code/extraction&
client_id=******&
code_challenge=Y29kZ*******

Если вы используете запрос POST, вы можете добавить зашифрованные в Base64 регистрационные данные пользователя в заголовок авторизации или разместить их в тексте запроса.

Если вы используете обнаружение пользователя без заголовка, вы не отправляете имя пользователя и пароль. Вместо этого вы отправляете идентификатор в параметре login_hint, дополнительные настраиваемые данные и пароль. Добавьте идентификатор, настраиваемые данные и пароль в текст запроса POST. Не используйте запрос GET.

По желанию, чтобы подключить этот поток к гостевому потоку без заголовка, можно добавить заголовок Uvid-Hint с маркером доступа на основе JWT, содержащим значение UVID, являющееся универсальным уникальным идентификатором версии 4, созданным и управляемым полностью приложением. Чтобы получить маркер доступа с UVID, необходимо включить приложение внешнего клиента или связанное приложение для выпуска маркеров доступа на основе JWT и внедрения потока без заголовка гостя в вашем приложении.

Если вы внедряете поток пользователя-гостя в приложение, вы можете по желанию использовать этот заголовок для передачи в маркер доступа на основе веб-маркера JSON (JWT), содержащий уникальный код посетителя (UVID), привязанный к удостоверению пользователя-гостя. Передавая UVID-файл в поток именованного пользователя, можно перенести контекстную информацию из сеанса пользователя-гостя, например, параметры cookie-файлов пользователя, в сеанс именованного пользователя.

Можно также добавить обычное значение UVID в текст запроса.

Примечание
Примечание При наличии параметра «Требовать регистрационные данные пользователя в тексте POST для кода авторизации и регистрационных данных» в приложении внешнего клиента или связанном приложении, вы можете отправить регистрационные данные пользователя только в тексте запроса. Если этот параметр включен, вы не сможете использовать метод GET для запроса кода авторизации. Можно использовать только метод POST.

В методах GET и POST добавьте следующие обязательные параметры в текст запроса на авторизацию.

ПараметрОписание
client_id Ключ пользователя приложения внешнего клиента или связанного приложения.
redirect_uri

URL-адрес, куда пользователи перенаправляются после успешной проверки подлинности. URI-адрес переадресации должен соответствовать одному из значений в поле «URL-адрес обратного вызова» в приложении внешнего клиента или связанном приложении. В противном случае утверждение не выполняется.

Для общедоступных клиентов URI-адрес переадресации должен указывать на конечную точку, которая может обработать переадресацию 302 из Salesforce. Чтобы упростить разработку, используйте конечную точку OAuth, например, https://MyExperienceCloudSite.my.site.com/services/oauth2/echo.

Эти примеры используют конечную точку извлечения кода Apex REST. Например, <Experience Cloud Domain>/services/apexrest/code/extraction.

response_type Тип предоставления OAuth 2.0, запрашиваемый приложением. Для кода авторизации и потока регистрационных данных значение должно code_credentials.

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

ПараметрОписание
code_challenge

Обязательно при использовании расширения PKCE. Указывает хэш-значение SHA256 значения code_verifier в запросе маркера. Установите этот параметр, чтобы предотвратить атаки перехвата кода авторизации. Значение должно быть зашифровано base64url, как определено в https://tools.ietf.org/html/rfc4648#section-5.

Этот параметр обязателен, если в запросе маркера указан code_verifier.

  • Если в запросе на авторизацию указано значение code_challenge, а в запросе на маркер указано значение code_verifier, Salesforce сравнивает code_challenge с code_verifier. Если code_challenge недействителен или не совпадает, вход не выполняется с кодом ошибки invalid_request.
  • Если значение code_challenge указано в запросе на авторизацию, но значение code_verifier не указано в запросе маркера, вход не выполняется с кодом ошибки invalid_grant.
scope Полномочия, определяющие тип защищаемых ресурсов, доступных приложению. Вы назначаете области внешнему клиентскому приложению или связанному приложению при его создании, и они добавляются в маркеры OAuth во время процесса авторизации. Если вы не добавите этот параметр, будут запрошены все области, назначенные приложению. Чтобы дополнительно ограничить области, передайте поднабор назначенных областей в этом параметре. Действительные параметры см. в разделе «Области OAuth».
state Любое состояние, запрашиваемое внешней веб-службой для отправки на URL-адрес обратного вызова. Это значение должно быть зашифровано как URL-адрес.
uvid_hint

Обычное значение UVID, то есть UUID версии 4, созданный и управляемый полностью приложением. Чтобы получить UVID, необходимо включить приложение внешнего клиента или связанное приложение для выдачи маркеров доступа на основе JWT и внедрения потока гостей без заголовка в вашем приложении. По желанию, этот параметр можно использовать для передачи значения UVID, связанного с личностью пользователя-гостя, перенося контекстную информацию из сеанса пользователя-гостя в сеанс названного пользователя.

Вместо передачи UVID в тексте запроса можно также передать его в маркере на основе JWT с UVID посредством заголовка UVID-Hint.

login_hint Обязательно при использовании обнаружения пользователя без заголовка. Идентификатор, используемый средством обработки Apex для поиска организации Salesforce пользователя. Например, соберите номер заказа пользователя в приложении и передайте его в параметре login_hint. Значение login_hint отправляется прямо в средство обработки Apex.
customdata

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

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

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

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

Пример средства обработки см. в разделе Auth.HeadlessUserDiscoveryHandler.

Salesforce проверяет регистрационные данные и возвращает 302-переадресацию на серверное средство обработки обратного вызова

Salesforce Headless Login API получает запрос авторизации. Он проверяет регистрационные данные пользователя и возвращает переадресацию HTTP 302 на готовый URL-адрес, содержащий код авторизации. Salesforce потом автоматически отправляет ответ переадресации на URL-адрес переадресации, который указывает на серверное средство обработки обратного вызова в конечной точке /code/extraction в данном примере. Во время этого процесса обозреватель не перенаправляется - все происходит фоном.

Серверное средство обработки обратного вызова извлекает код и возвращает его приложению

Серверное средство обработки обратного вызова извлекает код авторизации и другие данные. Пример средства обработки обратного вызова Apex использует метод doGet для извлечения кода, URL-адреса сайта Experience Cloud, кода сайта и состояния из переадресации 302.

@RestResource(urlMapping='/code/extraction')
global class CodeExtractorAPI {
  
   @HttpGet
   global static CodeResponse doGet() {
       RestRequest req = RestContext.request;
       RestResponse res = RestContext.response;
       try {
           res.statusCode = 200;
           return new CodeResponse(req.params.get('code'), req.params.get('sfdc_community_url'), req.params.get('sfdc_community_id'), req.params.get('state'));
       } catch (Exception e) {
           res.statusCode = 500;
           return new CodeResponse('Could not parse auth code redirect URI');
       }
      
   }
The response wrapper sets the variables for the code response, including success and error indicators.
// Response Wrapper
   global class CodeResponse {
       String code;
       String sfdc_community_url;
       String sfdc_community_id;
       String state;
       Boolean success;
       String errMsg;
      
       public CodeResponse(String code, String sfdc_community_url, String sfdc_community_id, String state) {
           this.code = code;
           this.sfdc_community_url = sfdc_community_url;
           this.sfdc_community_id = sfdc_community_id;
           this.state = state;
           this.success = true;
       }
      
        public CodeResponse(String errMsg) {
           this.success = false;
           this.errMsg = this.errMsg;
       }       
   }

Ниже указан еще один пример извлечения кода посредством PHP: Предпроцессор гипертекста (PHP).

<?
header('Access-Control-Allow-Headers: *');
header('Access-Control-Allow-Origin: *');
header('Content-Type: application/json; charset=utf-8');
$out = [];
foreach ($_GET as $name => $value) {
   $out[$name] = $value;
}
echo json_encode($out);
?>

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

Приложение получает ответ кода и выполняет обмен кодом

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

{"success":true,"state":"https://MyExperienceCloudSite.my.site.com/","sfdc_community_url":"https://MyExperienceCloudSite.my.site.com/vforcesite","sfdc_community_id":"0DBxxxxxxxxxxxx","errMsg":null,"code":"aPrxC1*******"}

Обозреватель без заголовка запрашивает обмен кода на маркер доступа. В примере клиентского JavaScript функция doCodeExchange отправляет код в запросе POST в конечную точку маркера Experience Cloud.

Во избежание открытия секрета пользователя обозревателю, необходимо отключить параметры «Требовать секрет для процесса веб-сервера» и «Требовать секрет для процесса проверки подлинности маркера обновления» в приложении внешнего клиента или связанном приложении. Если эти параметры отключены, секрет пользователя не обязателен в запросе на авторизацию. При возможности рекомендуем выполнить обмен кодами посредством серверного сервера. См. Headless Identity API: Код авторизации и поток регистрационных данных для частных клиентов.

var clientId = "<Connected App Client ID>";
var baseURL = "<Experience Cloud Domain>";
var redirectURL = "<Experience Cloud Domain>/services/apexrest/code/extraction"
      
// Performs the code exchange
function doCodeExchange(authorizeResponse) {
   //Perform Code Exchange
   //Get Access Token
   var client = new XMLHttpRequest();
   client.open("POST", authorizeResponse.sfdc_community_url + "/services/oauth2/token", true);
   client.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
   client.send("code=" + authorizeResponse.code + "&grant_type=authorization_code&client_id=" + clientId + "&redirect_uri=" + redirectURL);
   client.onreadystatechange = function() {
       if(this.readyState == 3) {
           response = JSON.parse(client.response);
           getUserInfo(response.access_token, response.sfdc_community_url)
       }
   }
} 

Для запроса маркера доступа можно использовать только запрос POST — запросы GET не поддерживаются. Необходимо добавить заголовок Content-Type. Добавьте следующие обязательные параметры в текст запроса.

ПараметрОписание
client_id Ключ пользователя приложения внешнего клиента или связанного приложения.
code Сервер авторизации создает код авторизации, являющийся кратковременным маркером, и передает его клиенту после успешной проверки подлинности. Клиент отправляет код авторизации на сервер авторизации для получения маркера доступа и, по желанию, маркера обновления.
grant_type Тип проверки, который может предоставить приложение для подтверждения безопасности посетителя. Для кода авторизации и потока регистрационных данных значение должно быть authorization_code.
redirect_uri

URL-адрес, куда пользователи перенаправляются после успешной проверки подлинности. URI-адрес переадресации должен соответствовать одному из значений в поле «URL-адрес обратного вызова» в приложении внешнего клиента или связанном приложении. В противном случае утверждение не выполняется.

Для общедоступных клиентов URI-адрес переадресации должен указывать на конечную точку, которая может обработать переадресацию 302 из Salesforce. Чтобы упростить разработку, используйте конечную точку OAuth, например, https://MyExperienceCloudSite.my.site.com/services/oauth2/echo.

Эти примеры используют конечную точку извлечения кода Apex REST. Например, <Experience Cloud Domain>/services/apexrest/code/extraction.

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

ПараметрОписание
client_secret Секрет пользователя приложения внешнего клиента или связанного приложения.
code_verifier

Обязательно при использовании расширения PKCE. Указывает 128 байтов случайных данных с высокой энтропией, чтобы затруднить угадывание значения code. Установите этот параметр, чтобы предотвратить атаки перехвата кода авторизации. Значение должно быть зашифровано base64url, как определено в https:// tools.ietf.org/html/rfc4648#section-5.

  • Если значение code_verifier указано в запросе маркера, а значение code_challenge находится в запросе авторизации, Salesforce сравнивает code_verifier с code_challenge. Если код_верификатор недействителен или не совпадает, вход не выполняется с кодом ошибки invalid_grant.
  • Если значение code_verifier указано в запросе маркера, но значение code_challenge не указано в запросе авторизации, вход не выполняется с помощью кода ошибки invalid_grant.
format

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

  • urlencoded
  • json (по умолчанию)
  • xml

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

После проверки регистрационных данных приложения Salesforce Headless Login API возвращает маркер доступа в обозреватель. Ниже указан пример ответа на маркер доступа в формате 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"
}

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

Параметр Описание
access_token Маркер OAuth, используемый внешним клиентским приложением или связанным приложением для запроса доступа к защищенному ресурсу от имени клиентского приложения. Маркер доступа может сопровождаться дополнительными полномочиями в виде областей.
id URL-адрес удостоверения, который можно использовать для идентификации пользователя и запроса дополнительных сведений о пользователе. См. раздел «URL-адреса удостоверений».
instance_url URL-адрес экземпляра организации пользователя. Например: https://yourInstance.salesforce.com/.
issued_at Отметка времени создания подписи, выраженная количеством миллисекунд с 1970-01-01T0:0:0Z UTC.
signature Подпись HMAC-SHA256, зашифрованная в Base64, подписанная client_secret. Подпись может содержать конкатенированный код и issued_at value, которые можно использовать для проверки того, что URL-адрес удостоверения не изменился с момента отправки сервером.
sfdc_community_url URL-адрес сайта Experience Cloud.
sfdc_community_id Код сайта Experience Cloud пользователя.
token_type Тип Bearer маркера, используемый для всех ответов, содержащих маркер доступа.

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

Параметр Описание
id_token

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

Этот параметр возвращается, если параметр области содержит openid.

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

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

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

Примечание
Примечание Убедитесь в выполнении полной проверки безопасности хранилища маркеров доступа. Не сохраняйте маркер доступа в локальном хранилище обозревателя и избегайте его сохранения в cookie-файле, если возможно.
// Gets User Info
function getUserInfo(accessToken, userInfoBaseURL) {
   var client = new XMLHttpRequest();
   client.open("GET", userInfoBaseURL + "/services/oauth2/userinfo", true);
   client.setRequestHeader("Content-Type", "application/json");
   client.setRequestHeader("Authorization", "Bearer " + accessToken);
   client.send();
   client.onreadystatechange = function() {
       if(this.readyState == 3) {
           response = JSON.parse(client.response);
           response.access_token = accessToken;
           document.getElementById("json").textContent = JSON.stringify(response, undefined, 2);
           document.getElementById("results").style.display="block";
       }
   }
}

Конечный пользователь вошел и выполняет действие в приложении

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

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

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

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

Конечный пользователь имеет доступ к данным Salesforce

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

 
Загрузка
Salesforce Help | Article