Tokens de acceso basados en JWT
Salesforce admite dos tipos de tokens de acceso: tokens opacos y tokens de acceso basados en tokens Web de JSON (JWT). Un token de acceso opaco tiene el formato una cadena que no puede descodificar a menos que llame al extremo Información de usuario de Salesforce. Un token de acceso basado en JWT tiene formato como un objeto JSON que contiene toda la información necesaria para autorizar la aplicación. Este formato transparente facilita el uso de tokens de acceso basados en JWT para servicios construidos fuera de la plataforma Salesforce. Puede analizar y validar fácilmente tokens de acceso basados en JWT de forma local en su servicio externo a la plataforma, sin llamar a un extremo de Salesforce. Al introspectar tokens de forma local, puede mejorar el desempeño y la eficiencia de sus flujos de autorización.
Ediciones necesarias
| Disponible en: Salesforce Classic y Lightning Experience |
| Disponible en: Todas las ediciones |
Comparado con los tokens de acceso opacos, los tokens de acceso basados en JWT tienen limitaciones y funciones diferentes. Por ejemplo, se pueden utilizar tokens de acceso basados en JWT solo para acceder a las API de REST. Para ver cómo se comparan los tipos de token, visite Tokens de acceso en Ayuda de Salesforce.
Puede emitir tokens de acceso basados en JWT para todos los flujos de autorización.
Formato de token
Los tokens de acceso basados en JWT utilizan la estructura de JWT, con un encabezado, una carga, y una firma. El encabezado tiene información acerca del token, como su tipo de token. La carga contiene un conjunto de reclamaciones con información sobre el token, el usuario y la aplicación. La parte de firma contiene la firma criptográfica del token. Esta firma consta del encabezado con codificación Base64 y la carga y un secreto firmados con el algoritmo especificado en la reclamación alg.
A continuación se incluye una descripción general detallada del encabezado y la carga.
| Reclamación de encabezado | Descripción |
|---|---|
alg (algoritmo) |
El algoritmo que se utiliza para firmar el token de acceso basado en JWT, permitiéndole verificar que no cambió desde que se emitió. Salesforce solo admite el algoritmo RS256, de modo que el valor de esta reclamación debe ser RS256. |
typ (tipo) |
El tipo de contenido almacenado en el token. Esta reclamación ayuda a las aplicaciones a distinguir el token de otros tipos de datos. Para tokens de acceso basados en JWT, este valor es JWT. |
kid (Id. de clave) |
Una cadena que está registrada con Salesforce indicando que se utilizó una clave para firmar el token, lo que ayuda a probar su autenticidad. |
tty (tipo de token) |
El tipo de token. El valor se establece en sfdc-core-token. |
tnk (clave de arrendatario) |
La clave de arrendatario que identifica la organización de Salesforce que emitió el token de acceso basado en JWT. Este valor se define de modo que Salesforce pueda encontrar y verificar las claves públicas correctas para esa organización. |
ver (versión) |
La versión de la biblioteca JWT. |
Este es un encabezado de ejemplo.
{
"tnk": "example/00XXXXXX",
"ver": "1.0",
"kid": "CORE_ATJWT************",
"tty": "sfdc-core-token",
"typ": "JWT",
"alg": "RS256"
}La carga siempre incluye estas reclamaciones.
| Reclamación de carga de trabajo | Descripción |
|---|---|
aud (audiencia) |
La audiencia dirigida del token de acceso de JWT según viene determinada por su caso de uso. La reclamación aud tiene el formato de una matriz JSON de cadenas. |
exp (hora de caducidad) |
Tiempo de caducidad del token de acceso de JWT. El token no se puede aceptar en este momento o después de este momento. La hora de caducidad debe ser posterior a la fecha y hora actuales. |
iss (emisor) |
La URL de inicio de sesión de Mi dominio o la URL del sitio de Experience Cloud que está emitiendo el token de acceso de JWT. Por ejemplo, NombreMiDominio.my.site.com. |
mty
|
Solo para uso interno. |
nbf (no antes de hora) |
El cliente debe recibir el JWT después de la fecha y hora expresadas en la reclamación nbf. Si el JWT se envía antes de esta fecha y hora, el cliente no puede aceptarlo. |
sfi
|
Identificador interno reservado para uso futuro. |
sub (asunto) |
Identifica el usuario el asunto del token de acceso de JWT. El valor
|
scp (ámbitos) |
Una lista de ámbitos admitidos de Salesforce, incluyendo ámbitos personalizados, con formato de una matriz JSON de nombres de ámbito. Los ámbitos se separan por espacios. El token puede incluir cualquier ámbito de Salesforce excepto el ámbito de full. |
La carga también puede incluir estas reclamaciones opcionales.
| Reclamación de carga de trabajo | Descripción |
|---|---|
acx
|
Solo para uso interno. |
client_id (clave de consumidor) |
La clave de consumidor de la aplicación cliente externa de Salesforce o la aplicación conectada que emitió el token. |
iat (emitido a las) |
La hora a la que se emite el JWT. Puede utilizar el valor de esta reclamación para determinar cuán antiguo es el JWT. |
roles (lista de funciones) |
Define las propiedades del token que los servicios pueden utilizar para controlar el acceso, como los conjuntos de permisos y funciones. Salesforce controla completamente los valores en esta reclamación. La reclamación no incluye una lista completa de los privilegios de acceso de un usuario. Por ejemplo, un conjunto de permisos asignado al usuario a veces no se muestra en esta lista. Los valores en esta reclamación tienen formato de una matriz de cadenas con prefijo. Salesforce admite estos prefijos.
En ocasiones, esta reclamación es una matriz vacía. |
obo (en nombre de) |
Cualquiera que tenga el token puede completar acciones en nombre del valor de esta reclamación. Para Salesforce, esta reclamación se utiliza para vincular una UVID a un usuario nombrado cuando pasa un token de invitado a un flujo de usuario nombrado. El token de invitado contiene la UVID en la reclamación sub. Tras completar un flujo de usuario nombrado, el nuevo token de acceso pone la UVID en la reclamación obo y almacena el Id. de usuario en la reclamación sub. |
Esta es una carga de trabajo de ejemplo. Debido a que este ejemplo tiene un UVID en la reclamación obo, puede asumir que este token se emitió tras pasar un UVID en un flujo de usuario nombrado.
{
"scp": "api",
"aud": [
"https://example.com"
],
"sub": "uid:005x00000000001",
"nbf": "1675197036",
"iss": "https://example.com", "exp": "1675198836",
"iat": "1675197036",
“obo”: “uvid:abcd-1234-efgh”,
"client_id": "***********",
“mty”: “oauth”,
“sfi”: “********”
}
