OAuth 2.0 para aplicaciones de primera parte: Flujo de registro desatendido para clientes privados

Paso 1: El usuario abre la aplicación de primera parte y hace clic en Registrar

Un usuario abre su aplicación de primera parte y hace clic en un vínculo de registro. O bien hacen clic en un vínculo para acceder a un recurso que requiere registro.

Paso 2: La aplicación de primera parte muestra el formulario de registro

En su aplicación de primera parte, muestra de forma nativa un formulario de registro para recopilar información acerca del usuario. Usted controla todo acerca de este formulario, incluyendo su aspecto, su comportamiento y la información de usuario que desea recopilar.

Existen algunas consideraciones sobre la información que desea recopilar de usuarios. Cuando su aplicación envía información de usuario al extremo de desafío de autorización, Salesforce comprueba una dirección de email, un nombre de usuario, un apellido y una contraseña. Puede recopilar esta información a usuarios o generarla automáticamente, pero debe incluirse en su solicitud POST. Cuando decida qué información incluir, asegúrese de recopilar una dirección de email o número de teléfono de modo que el usuario pueda verificar su identidad.

Paso 3: El usuario ingresa su información

En el formulario de registro de su aplicación, el usuario ingresa su información.

Paso 4: La aplicación de primera parte acuña un JWT de certificado de cliente y genera valores de code_verifier y code_challenge para PKCE

La aplicación acuña un JWT de certificado de cliente.

La aplicación también genera valores para los parámetros PKCE utilizados para verificar el código de autorización.

Nota Recomendamos encarecidamente que implemente siempre PKCE para este flujo. De lo contrario, no obtiene sus beneficios de seguridad.

Para obtener más información sobre PKCE, consulte la especificación RFC 7636: Clave de prueba para el intercambio de códigos por clientes públicos de OAuth proporcionado por Internet Engineering Task Force (IETF).

La especificación de la extensión PKCE definida en RFC 7636 también incluye un parámetro code_challenge_method opcional que puede enviar en la solicitud de autorización. Salesforce no tendrá en cuenta cualquier valor que se envíe en este parámetro, y establecerá SHA256 de forma predeterminada.

Paso 5: La aplicación envía una solicitud inicial al extremo de reto de autorización

Desde el navegador, su aplicación envía una solicitud POST al extremo services/oauth2/v1/authorization_challenge en su sitio de Experience Cloud.

Incluya este encabezado en su solicitud si es necesario.

Incluya estos parámetros en el cuerpo de la solicitud.

A continuación se incluye un ejemplo de solicitud de registro inicial.

POST /services/oauth2/v1/authorization_challenge? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com
{
    "userdata": {
        "firstname": "Janice"
        "lastname": "Edwards"
        "email": "janice.edwards@example.com"
        "username": "jedwards@myapp.com"
        }
    "customdata": {
        "mobilePhone"="<mobile phone number>"
        }
    "password":"*********"
    "recaptcha": "*******"
    "login_type": "email"
    "emailtemplate": "unfiled$public/SalesNewCustomerEmail"
    "client_assertion": "Y2xpZW50YXNzZXJ0aW9u..."
}

Paso 6: Salesforce valida la solicitud

Salesforce intenta primero validar el token JWT de certificado de cliente validando que la firma pasada en el parámetro client_asssertion coincida con la firma para el certificado configurado de la aplicación cliente externa.

Si el JWT de certificado de cliente no es válido, Salesforce devuelve un error invalid_attestation y hay que volver a enviar la solicitud con todos los parámetros que se enviaron originalmente. A continuación se incluye un ejemplo de respuesta de error.

Si el JWT del certificado de cliente es válido, pero hay otros problemas con la solicitud, Salesforce devuelve una respuesta de error especificando qué falla con la solicitud. La respuesta también incluye un parámetro auth_session que es válido durante 5 minutos tras su emisión. Durante el periodo de tiempo en el que la sesión auth_session es válida, la puede utilizar para volver a enviar la solicitud. En las versiones corregidas que vuelva a enviar, incluya solo los valores corregidos para los parámetros que provocaron el fallo de la solicitud. También debe volver a enviar la password con cada solicitud porque Salesforce no la almacena. Los otros parámetros que no provocaron el fallo de la solicitud se pueden excluir. Ya están representados por auth_session.

Nota Los parámetros del sistema reCAPTCHA no se vinculan a auth_session, pero puede volver a enviar la solicitud sin ellos, a no ser que hayan causado el fallo de la solicitud.

Por ejemplo, si su token JWT de certificado de cliente es válido pero la solicitud falla porque el nombre de usuario no era correcto, vuelva a enviar una solicitud que incluya solo la sesión auth_session, el username y la password.

Paso 7: Salesforce envía una OTP al usuario

Si la solicitud se realiza correctamente, Salesforce aún devuelve una respuesta de error porque aún no puede otorgar el código de autorización. Pero esta vez, la respuesta de error indica que se inicializó el inicio de sesión y que Salesforce envió una OTP a la dirección de email o el número de teléfono del usuario. Para confirmar que la solicitud se realizó correctamente, busque el código de error login_initialized y el estado otp_sent. La respuesta también incluye un parámetro auth_session, que es importante para el siguiente paso.

A continuación se incluye un ejemplo de respuesta.

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store

{
  "error": "authorization_required",
  "auth_session": "uY29tL2F1dGhlbnRpY",
  "error_code": "login_initialized",
  "login_status": {
    "type": "SMS",
    "state": "otp_sent",
    "displayData": "+120******58"
   }
}

Paso 8: Su aplicación muestra de forma nativa un formulario de verificación

En su aplicación de primera parte, muestra un formulario de verificación donde el usuario final puede ingresar su OTP. El aspecto de este formulario depende completamente de usted.

Paso 9: El usuario ingresa OTP en el formulario de verificación

El usuario recibe la OTP y la ingresa en el formulario de verificación en su aplicación de primera parte.

Paso 10: Su aplicación solicita un código de autorización

Para solicitar un código de autorización, su aplicación envía el parámetro auth_session y la contraseña simultánea (OTP por sus siglas en inglés) que el usuario especificó al extremo de reto de autorización utilizando otra solicitud POST a services/oauth2/v1/authorization_challenge. Esta solicitud no tiene encabezados obligatorios. Incluya estos parámetros en el cuerpo de la solicitud.

A continuación se incluye un ejemplo de solicitud.

POST /authorize HTTP/1.1
Host: MyExperienceCloudSite.my.site.com

auth_session=uY29tL2F1dGhlbnRpY*
login_otp=<otp_from_sms>

Paso 11: Salesforce devuelve un código de autorización

Si la OTP es correcta y la solicitud auth_session es válida, Salesforce devuelve un código de autorización y finaliza la auth_session. A continuación se incluye un ejemplo de respuesta de código de autorización.

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store

{
  "authorization_code": "uY29tL2F1d******"
}

Paso 12: Su aplicación intercambia el código de autorización por un token de acceso

Después de obtener el código de autorización, su aplicación envía una solicitud al extremo del token de Salesforce.

Esta solicitud no tiene encabezados. Incluya estos parámetros en el cuerpo de la solicitud.

A continuación se incluye una solicitud de token de ejemplo.

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

code=********&
client_id=**********&
client_secret=*********&
redirect_uri=<callback_URL>&
grant_type=authorization_code&
code_verifier=*******

Paso 13: Salesforce otorga un token de acceso

Después de validar las credenciales de la aplicación. Salesforce devuelve un token de acceso. A continuación se incluye un ejemplo de respuesta de token de acceso en 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"
}

La respuesta del token de acceso contiene estos parámetros.

Paso 14: La aplicación crea la sesión del usuario

Su aplicación procesa la respuesta del token y crea la sesión del usuario.

Paso 15: El usuario está registrado y realiza una acción en la aplicación

Su usuario está ahora registrado e inició sesión. Realiza una acción en su aplicación que requiere acceso a datos de Salesforce. Por ejemplo, hace clic en un botón para ver su historial de reserva de viajes, que se almacena en Salesforce.

Nota Cuando configura su aplicación cliente externa o aplicación conectada para el flujo Código de autorización y credenciales, establece la política Usuarios permitidos en Usuarios aprobados por el administrador se han autorizado previamente y configura qué perfiles o conjuntos de permisos pueden acceder a la aplicación. Con esta política, los usuarios acceden a la aplicación sin autorizarla, de modo que no obtienen una pantalla de autorización solicitándoles permitir a la aplicación acceder a sus datos.

Paso 16: La aplicación realiza una llamada autenticada a un extremo de Salesforce

Para acceder a los datos de Salesforce del usuario, su aplicación utiliza el token de acceso para realizar una llamada autenticada a un extremo de Salesforce protegido, como una API de Salesforce.

Paso 17: El usuario puede acceder a datos de Salesforce

El usuario puede ahora acceder a datos de Salesforce protegidos en su aplicación. Por ejemplo, puede ver su historial de reserva de viajes.