APIs de identidade autônomos: Fluxo de login sem senha autônomo para clientes particulares
Para simplificar o processo de login para seu aplicativo fora da plataforma, configure o Fluxo de login sem senha autônomo. Os usuários fazem login no seu aplicativo inserindo o endereço de email ou o número de telefone e confirmando sua identidade com uma senha de uso único (OTP). No front-end, você controla a experiência do usuário em seu aplicativo. No back-end, seu aplicativo chama a API de Login sem senha autônomo por meio de um site do Experience Cloud para fazer o login do usuário. Estas etapas mostram como o fluxo funciona com um cliente privado, como um aplicativo de servidor cliente tradicional que pode manter as informações confidenciais.
Edições obrigatórias
| Disponível em: Salesforce Classic (não disponível em todas as organizações) e Lightning Experience |
| Disponível em: Enterprise, Unlimited e Developer Editions |
Esse fluxo é uma variação do Fluxo de credenciais e código de autorização, que amplia o tipo de concessão de código de autorização OAuth 2.0. Como outras variações, ele inclui chamadas para pontos de extremidade do Salesforce para obter um código de autorização e troca-lo por um token de acesso. Nessa variação, o aplicativo troca um identificador de solicitação e uma OTP pelo código de autorização em vez de um nome de usuário e senha, como acontece em um fluxo de login autônomo mais tradicional. Então, o código é trocado por um token de acesso.
Antes de configurar esse fluxo, conclua estas etapas.
- Preencha os pré-requisitos da identidade autônoma
- Integre seu aplicativo fora da plataforma ao Salesforce usando uma destas opções.
- Defina as configurações do Experience Cloud para login sem senha autônomo
Aqui você encontra um exemplo de caso de uso do Fluxo de login sem senha autônomo. Você trabalha para uma empresa de viagens que gerencia informações do cliente no Salesforce e já usa o login e o registro autônomo no seu aplicativo fora da plataforma. Durante o processo de registro, colete o endereço de email do usuário. Para tornar o processo de login mais fácil, configure o login sem senha autônomo com email como o método de verificação. Agora, quando os usuários acessarem seu aplicativo, eles poderão inserir o endereço de email e receber uma OTP. Depois de o usuário inserir a OTP no aplicativo e o Salesforce verificar sua identidade, o usuário é conectado e pode acessar dados protegidos do Salesforce, como seu histórico de viagens.
Opcionalmente, para ainda mais flexibilidade com sua experiência de usuário, você pode usar um manipulador do Apex de descoberta de usuário autônomo para recuperar usuários. Desenvolva seu manipulador para pesquisar usuários com base em seu endereço de email, número de telefone ou qualquer outro identificador que possa ser vinculado a um usuário do Salesforce. Por exemplo, solicite que os usuários façam login com o número de confirmação de viagem. Quando o usuário insere seu número de confirmação, o Salesforce localiza o nome de usuário associado e envia uma OTP para o endereço de email do usuário. Para obter mais informações sobre como desenvolver seu manipulador do Apex, consulte Auth.HeadlessUserDiscoveryHandler no guia de referência do Apex.
Para um cliente privado que possa armazenar com segurança o segredo do consumidor do aplicativo em seu próprio back-end, recomendamos proteger seu fluxo autenticando suas chamadas à API de login sem senha autônomo. Sempre habilite Exigir autenticação para acessar esta API nas configurações do Experience Cloud e inclua um token de acesso emitido para um usuário de integração interno na sua solicitação inicial para o ponto de extremidade services/auth/headless/init/passwordless/login. Para obter o token de acesso, use um fluxo OAuth 2.0 padrão, como o fluxo de usuário-agente. Para o aplicativo cliente externo ou aplicativo conectado que você usa para o fluxo padrão OAuth, inclua o escopo pwdless_login_api para que ele seja refletido em seu token de acesso.
Opcionalmente, você pode adicionar uma camada extra de segurança habilitando Exigir reCAPTCHA para acessar essa API nas configurações do Experience Cloud e implementando reCAPTCHA no seu aplicativo. Porém, chamadas de API autenticadas são a melhor linha de defesa principal para um cliente privado.
Para proteger ainda mais seu fluxo, sempre recomendamos implementar a extensão de Chave de comprovação para Code Exchange (PKCE) do OAuth 2.0.
Para expandir suas opções de modelo de email para o email de senha de uso único (OTP) enviado aos usuários finais durante o fluxo, aceite a criação da lista de permissão de modelo de email e crie uma lista de permissão com modelos personalizados. Consulte Usar diversos modelos de email para fluxos autônomos.
Aqui está uma visão geral do fluxo de login sem senha autônomo para um cliente privado.
- Um usuário final abre o aplicativo e vê um formulário de login exibido nativamente no seu aplicativo. Ele insere o endereço de email ou o número de telefone solicitado pelo formulário de login (1).
- Se você não estiver usando um manipulador de descoberta de usuário autônomo, seu aplicativo encontrará o nome de usuário associado ao número de telefone ou endereço de email do usuário (2).
- Seu aplicativo envia uma solicitação POST autônoma para a API de login sem senha autônomo, o ponto de extremidade
services/auth/headless/init/passwordless/loginem seu site do Experience Cloud (3). - (Opcional) Se você estiver usando um manipulador autônomo de descoberta de usuário, o manipulador encontrará o nome de usuário associado aos dados passados no parâmetro
login_hinte verificará se o endereço de email ou número de telefone associado ao usuário foi verificado. - O Salesforce retorna uma mensagem de sucesso para seu aplicativo. Ele também envia um identificador de solicitação que será usado posteriormente no fluxo (4a).
- Dependendo do método de verificação, o Salesforce envia um email ou uma mensagem de texto SMS com uma OTP para o usuário (4b).
- Seu aplicativo exibe nativamente um formulário de verificação de OTP (5).
- O usuário recebe a OTP e a insere no seu aplicativo (6).
- Se você estiver usando a PKCE (o que é recomendado), seu aplicativo gerará parâmetros PKCE (7).
- Seu aplicativo inicia o Fluxo de credenciais e código de autorização com uma solicitação POST ou GET para o ponto de extremidade de autorização do Salesforce (
services/oauth2/authorize). A solicitação inclui o ID da solicitação e a OTP, assim como outros parâmetros para identificar o aplicativo e especificar o tipo de solicitação (8). - O Salesforce verifica o ID e a OTP da solicitação e retorna um redirecionamento 302 para um URL pré-configurado que contém o código de autorização. Se o fluxo estiver sendo executado no navegador, o redirecionamento 302 será processado no navegador e a resposta será entregue de forma autônoma ao ponto de extremidade de retorno de chamada do lado do servidor (9).
- O manipulador de retorno de chamada no lado do servidor extrai o código e outros parâmetros do redirecionamento 302 e inicia a troca de código com uma solicitação POST para o ponto de extremidade do token (10).
- O Salesforce valida a solicitação de token e retorna um token de acesso e o estado (11).
- O manipulador de retorno de chamada no lado do servidor processa a resposta do token e retorna o estado conectado ao aplicativo. Essa resposta pode incluir detalhes da sessão, informações do usuário e, possivelmente, o token de acesso (12).
- Seu aplicativo recebe resposta do token e cria a sessão do usuário (13).
- Agora, o usuário está conectado e executa uma ação no seu aplicativo, como clicar em um botão para ver o histórico de pedidos (14).
- Seu aplicativo envia uma solicitação autenticada para uma API do Salesforce protegida (15).
- Agora, o usuário pode acessar seus dados Salesforce em seu aplicativo fora da plataforma (16).
Como mencionado na etapa 10, para um cliente privado, crie um manipulador de retorno de chamada no lado do servidor que possa extrair o redirecionamento 302 e retornar um código de autorização ao seu aplicativo. Para ver como você pode criar esse manipulador, consulte Fluxo de credenciais e código de autorização para clientes particulares, que inclui um exemplo de manipulador do Apex exposto como um recurso REST.
O usuário final insere o endereço de email ou o número de telefone para login
O fluxo começa quando um usuário final acessa seu aplicativo. Seu aplicativo exibe nativamente um formulário de login que solicita apenas o endereço de email ou o número de telefone do usuário. Ou, se você estiver usando um manipulador de descoberta de usuário autônomo que pesquise usuários com base em um identificador diferente, como um número de pedido, seu aplicativo poderá exibir um formulário de login solicitando ao usuário o identificador. O usuário final insere suas informações e clica em um botão para fazer login.
Seu aplicativo encontra o nome de usuário
Se você não estiver usando um manipulador de descoberta de usuário autônomo, seu aplicativo pesquisará o endereço de email ou número de telefone do usuário e encontrará o nome de usuário associado.
Se você estiver usando um manipulador de descoberta de usuário autônomo, seu aplicativo ignorará essa etapa. Seu manipulador procura o usuário depois de enviar a solicitação inicial.
Seu aplicativo envia uma solicitação para a API de login sem senha autônoma
No navegador, seu aplicativo envia uma solicitação POST autônoma para o ponto de extremidade de login sem senha autônomo (services/auth/headless/init/passwordless/login) no site do Experience Cloud.
Inclua um cabeçalho para autenticar sua solicitação.
| Parâmetro | Obrigatório? | Descrição |
|---|---|---|
Authorization
|
Necessário se você habilitar Exigir autenticação para acessar essa API em suas configurações do Experience Cloud. Isso é recomendado para clientes privados. | Um cabeçalho do portador contém um token de acesso emitido para um usuário de integração interno. Para obter o token de acesso, você pode usar qualquer fluxo OAuth padrão compatível com o Salesforce. Certifique-se de atribuir o escopo pwdless_login_api ao seu aplicativo cliente externo ou ao aplicativo conectado ou passá-lo como um parâmetro durante o fluxo. |
Inclua estes parâmetros no corpo da solicitação.
| Parâmetro | Obrigatório? | Descrição |
|---|---|---|
verificationmethod
|
Sim. | O método usado para verificar a identidade do usuário. Você pode usar email ou sms. |
username
|
Obrigatório se você não estiver usando um manipulador de descoberta de usuário autônomo. | O nome de usuário vinculado ao endereço de email ou ao número de telefone que o usuário enviou. |
recaptcha
|
Obrigatório se estas condições se aplicam a você:
|
Um token criptografado emitido pela API reCAPTCHA do Google quando um usuário conclui um desafio de reCAPTCHA. |
recaptchaevent |
Obrigatório se estas condições se aplicam a você:
|
Um objeto JSON contendo estes subparâmetros.
Para obter mais informações, consulte a documentação do Google reCAPTCHA. |
emailtemplate
|
Obrigatório para especificar vários modelos de email se a criação de listas de permissão de modelos de email estiver habilitada. Se você não tiver habilitado a criação de listas de permissão de modelos de email, não poderá incluir este parâmetro. Se você não incluir esse parâmetro, o Salesforce usará o modelo de email padrão definido em suas configurações do Experience Cloud, independentemente de a lista de permissão estar habilitada ou não. Se não houver um modelo configurado, o Salesforce usará um modelo de email de OTP padrão. O idioma do modelo de email para modelos padrão é controlado pelas configurações de idioma do usuário no Salesforce. |
O nome do desenvolvedor do modelo de email personalizado. Esse parâmetro pode incluir apenas um modelo de email da lista de permissão. Para controlar o idioma de um modelo de email personalizado, crie modelos no idioma desejado |
login_hint
|
Necessário se você estiver usando um manipulador do Apex de descoberta de usuário autônomo. | Um identificador que seu manipulador do Apex pode usar para localizar a conta do Salesforce de um usuário. Por exemplo, colete o número do pedido de um usuário no seu aplicativo e passe-o no parâmetro login_hint. Enviamos o valor login_hint diretamente para o manipulador do Apex. |
Aqui está uma solicitação de exemplo para a API de login sem senha autônomo. Neste exemplo, a autenticação é necessária, mas o reCAPTCHA não. Essa solicitação é para uma implementação que não usa um manipulador de descoberta de usuário autônomo.
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"
}Aqui está um exemplo de solicitação se você estiver usando um manipulador de descoberta de usuário autônomo.
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"
}(Opcional) O Manipulador de descoberta de usuário autônomo encontra o usuário
Se você estiver usando um manipulador autônomo de descoberta de usuário, o manipulador pega o parâmetro login_hint e encontra o usuário associado. O manipulador confirma que o endereço de email ou número de telefone do usuário foi verificado.
Para obter um exemplo de manipulador, consulte Auth.HeadlessUserDiscoveryHandler no Guia de referência do Apex.
O Salesforce retorna um identificador da solicitação para seu aplicativo
Se a solicitação for bem-sucedida, o Salesforce enviará de volta uma mensagem de sucesso que inclui um identifier para a solicitação, ou que é importante mais tarde no fluxo, quando for feita a troca por um token de acesso. Aqui está um exemplo de mensagem de sucesso.
{
"status": "success",
"email": "jedwards@example.com",
"identifier": "0RXXXXXXXX"
}O Salesforce envia uma OTP para o usuário
Imediatamente após o Salesforce enviar o identificador da solicitação ao seu aplicativo, ele também envia ao usuário um email ou mensagem de texto SMS com a OTP.
Seu aplicativo exibe um formulário de verificação
Em seu aplicativo, você exibe nativamente um formulário de verificação em que o usuário pode inserir sua OTP.
O usuário final insere uma OTP
O usuário final recebe a OTP por email ou mensagem de texto e a insere no formulário de em seu aplicativo verificação.
Seu aplicativo gera parâmetros para PKCE
Se você estiver usando a extensão PKCE (o que é recomendado), seu aplicativo gerará os parâmetros code_verifier e code_challenge.
A especificação PKCE definida em RFC 7636 também inclui um parâmetro code_challenge_method opcional que pode ser enviado na solicitação de autorização. O Salesforce ignora qualquer valor enviado nesse parâmetro e o padrão é SHA256.
Seu aplicativo envia uma solicitação ao ponto de extremidade de autorização
Assim que o usuário verificar a identidade inserindo a OTP, seu aplicativo inicializa o Fluxo de credenciais e código de autorização com uma solicitação para o ponto de extremidade de autorização, em que troca o ID da solicitação e a OTP para um código de autorização.
Inclua estes cabeçalhos na solicitação de autorização.
| Cabeçalho | Obrigatório? | Descrição |
|---|---|---|
Auth-Request-Type
|
Sim. | Especifica o tipo de solicitação que você deseja fazer ao Salesforce. Para login sem senha autônomo, esse valor deve ser definido como passwordless-login. |
Auth-Verification-Type
|
Sim. | O método usado para verificar a identidade do usuário. O Salesforce oferece suporte a dois valores para o método de verificação: email e sms. |
Authorization
|
Sim. | Um cabeçalho básico identifica a solicitação de login sem senha, de modo que o Salesforce possa vincular a solicitação às informações armazenadas do usuário. Inclua o identificador da solicitação ( |
Uvid-Hint
|
Não. Se você implementar o fluxo de usuário convidado em seu aplicativo, poderá usar opcionalmente esse cabeçalho para passar um token de acesso baseado em JSON Web Token (JWT) contendo um ID de visitante exclusivo ( Em vez de passar um token baseado em JWT com um |
Um token de acesso baseado em JWT contendo um valor UVID, que é um identificador universalmente exclusivo (UUID) versão 4 gerado e gerenciado inteiramente pelo seu aplicativo. Para obter um token de acesso com um UVID, você deve habilitar seu aplicativo cliente externo ou aplicativo conectado para emitir tokens de acesso baseados em JWT e implementar o fluxo de convidado autônomo em seu aplicativo. |
Inclua estes parâmetros no corpo da solicitação.
| Parâmetro | Obrigatório? | Descrição |
|---|---|---|
response_type
|
Sim. | O tipo de concessão do OAuth 2.0 que o aplicativo conectado solicita. Para o Fluxo de credenciais e código de autorização, esse valor deve ser code_credentials. |
client_id
|
Sim. | O aplicativo cliente externo ou a chave de consumidor do aplicativo conectado. |
redirect_uri
|
Sim. | O URL para o qual os usuários são redirecionados depois de uma autenticação bem-sucedida. O Para clientes privados, use um |
code_challenge
|
Somente se você estiver usando PKCE. A PKCE é altamente recomendada. | Especifica o valor de hash SHA256 do valor Se Se |
uvid_hint
|
Não. Se você implementar o fluxo de usuário convidado no seu aplicativo, poderá usar como opção esse parâmetro para passar em um valor do Em vez de passar o |
Um valor UVID simples, que é um UUID versão 4 gerado e gerenciado totalmente pelo seu aplicativo. Para obter um UVID, você deve habilitar seu aplicativo cliente externo ou aplicativo conectado para emitir tokens de acesso baseados em JWT e implementar o fluxo de convidado autônomo em seu aplicativo. |
Aqui está um exemplo de solicitação para o ponto final de autorização. Este exemplo inclui 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=********
O Salesforce verifica a solicitação e retorna um redirecionamento 302
Quando a solicitação chega ao ponto de extremidade de autorização, o Salesforce verifica o identificador da solicitação e a OTP. Então, o Salesforce retorna um redirecionamento HTTP 302 para um URL pré-configurado que contém o código de autorização. Se o fluxo estiver ocorrendo no navegador, o redirecionamento 302 será processado no navegador e o Salesforce enviará automaticamente a resposta de redirecionamento ao URL de redirecionamento, que é o ponto de extremidade de retorno de chamada no lado do servidor. Aqui você encontra um URL de exemplo pré-configurado.
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=0DBxxxxxxxxxxxxO manipulador de retorno de chamada no lado do servidor extrai o código e executa a troca de código
O manipulador de retorno de chamada no lado do servidor extrai o código de autorização e outros os parâmetros do redirecionamento 302. Em seguida, inicia a troca de código enviando uma solicitação POST autônoma para o ponto final do token.
Essa solicitação não tem cabeçalhos. Inclua estes parâmetros no corpo da solicitação.
| Parâmetro | Obrigatório? | Descrição |
|---|---|---|
code
|
Sim. | O servidor de autorização cria um código de autorização, que é um token de vida curta, e o passa ao cliente após a autenticação bem-sucedida. O cliente envia o código de autorização ao servidor de autorização para obter um token de acesso e, opcionalmente, um token de atualização. |
client_id
|
Sim. | A chave de consumidor do aplicativo cliente externo ou do aplicativo conectado. |
client_secret
|
Sim. | O segredo do consumidor do aplicativo cliente externo ou do aplicativo conectado. Nesse fluxo, ele atua como uma senha que o aplicativo usa para acessar o Salesforce. |
redirect_uri
|
Sim. | O URL para o qual os usuários são redirecionados depois de uma autenticação bem-sucedida. O URI de redirecionamento deve corresponder a um dos valores no campo URL de retorno do aplicativo conectado ou no aplicativo cliente externo. Caso contrário, a aprovação falhará. Esse valor deve ser codificado por URL. Para clientes privados, use um |
grant_type
|
Sim. | O tipo de validação que o aplicativo pode fornecer para comprovar que é um visitante seguro. Para o Fluxo de credenciais e código de autorização, o valor deve ser authorization_code. |
code_verifier
|
Somente se você estiver usando PKCE. | Especifica 128 bytes de dados aleatórios com alta entropia para dificultar adivinhar o valor do código. Defina esse parâmetro para ajudar a prevenir ataques de interceptação de código de autorização. O valor deve estar codificado com base64url conforme definido em https://datatracker.ietf.org/doc/html/rfc4648#section-5. Se houver um valor Se o valor |
Veja um exemplo de solicitação de token. Este exemplo usa 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=*******O Salesforce concede um token de acesso
Depois de validar as credenciais do aplicativo. O Salesforce retorna um token de acesso para o manipulador de retorno de chamada no lado do servidor. Veja aqui um exemplo de resposta de token de acesso no formato 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"
}A resposta do token de acesso contém estes parâmetros.
| Parâmetro | Obrigatório? | Descrição |
|---|---|---|
access_token
|
Sim. | Token OAuth que um aplicativo cliente externo ou aplicativo conectado usa para solicitar acesso a um recurso protegido em nome do aplicativo cliente. Permissões adicionais na forma de escopos podem acompanhar o token de acesso. |
id
|
Sim. | Um URL de identidade que pode ser usado para identificar o usuário e consultar mais informações sobre o usuário. Veja os URLs de identidade. |
id_token
|
Não. | Uma estrutura de dados assinada que contém atributos de usuário autenticado, incluindo um identificador exclusivo para o usuário e um carimbo de data e hora de quando o token foi emitido. Ela também identifica o aplicativo que faz a solicitação. Consulte Especificações do OpenID Connect. |
instance_url
|
Sim. | Um URL que indica a instância da organização do usuário. Por exemplo, https://yourInstance.salesforce.com/. |
issued_at
|
Sim. | Um carimbo de data/hora de quando a assinatura foi criada, expresso como o número de milésimos de segundo de 1970-01-01T0:0:0Z UTC. |
refresh_token
|
Não. | Token obtido do servidor da Web, do agente do usuário ou do fluxo do token do aplicativo híbrido. Este valor é secreto. Tome medidas adequadas para protegê-lo. Esse parâmetro é retornado somente se o aplicativo cliente externo ou aplicativo conectado estiver configurado com um escopo refresh_token. |
signature
|
Sim. | Assinatura HMAC-SHA256 com codificação Base64 realizada com client_secret. A assinatura pode incluir ID concatenado e valor issued_at, que você pode usar para verificar se o URL da identidade não mudou desde que o servidor o enviou. |
sfdc_community_url
|
Sim. | O URL do site do Experience Cloud. |
sfdc_community_id
|
Sim. | O ID do site do Experience Cloud do usuário. |
state
|
Não. | O estado solicitado pelo cliente. Esse valor será incluído somente se o parâmetro state estiver na string de consulta original. |
token_type
|
Sim. | Um tipo de token Bearer, que é usado para todas as respostas que incluem um token de acesso. |
O manipulador de retorno de chamada no lado do servidor processa a resposta do token
Para obter o token de acesso, o manipulador de retorno de chamada processa a resposta e, então, retorna o token de acesso e o estado para o navegador junto com os dados do usuário, os tokens e os dados da sessão. Como prática recomendada, recomendamos que você configure seu servidor para armazenar o token de acesso, criar uma sessão para o aplicativo e retornar a sessão ao aplicativo, em vez de retornar o token de acesso. Como desenvolvedor, você está no controle total da criação da sessão, do armazenamento do token de acesso e do gerenciamento do estado conectado, portanto, então a implementação específica fica a seu critério.
Aqui está um exemplo de uma resposta bem-sucedida no log do console do navegador.
{
"success":true,
"state":"https://MyExperienceCloudSite.my.site.com/",
"errMsg":"null",
"access_token":"00*******"
}
O aplicativo cria a sessão do usuário
O aplicativo recebe a resposta de token de acesso e cria a sessão do usuário.
O usuário está conectado e executa uma ação no aplicativo
Agora, o usuário está conectado e executa uma ação no seu aplicativo que solicita o acesso a dados do Salesforce. Por exemplo, ele clica em um botão para visualizar seu histórico de pedido, que é armazenado no Salesforce.
O aplicativo faz uma chamada autenticada para um ponto final do Salesforce
Para acessar os dados do Salesforce do usuário, o aplicativo usa o token de acesso para fazer uma chamada autenticada para um ponto final do Salesforce protegido, como uma API do Salesforce.
O usuário consegue acessar os dados do Salesforce
Agora o cliente pode acessar os dados protegidos do Salesforce em seu aplicativo. Por exemplo, ele pode ver seu histórico de pedidos. Da perspectiva do usuário, todo o processo, desde o login até o acesso aos dados, ocorreu sem exigir que o usuário saísse do aplicativo.
