Saltar al contenido principal

La disponibilidad varía según el plan de Auth0

Tu plan de Auth0 o tu acuerdo personalizado determinan si esta funcionalidad está disponible. Para obtener más información, consulta Precios.
La mayoría de los tokens de identidad (ID) y los que devuelve Auth0 son (JWT) que contienen diversos claims, es decir, fragmentos de información declarados sobre un sujeto. Por ejemplo, un token de ID (que siempre es un JWT) puede contener un claim llamado name que indica que el nombre del usuario que se autentica es “John Doe”. Hay dos tipos de claims de JWT:
  • Registrados: Claims definidos por la especificación JWT para garantizar la interoperabilidad con aplicaciones de terceros o externas. Los claims estándar de OpenID Connect (OIDC) son claims reservados.
  • Personalizados: Claims que defines tú mismo. Estos claims pueden ser claims públicos no registrados y resistentes a colisiones, o claims privados no registrados y no públicos sujetos a colisión. Asigna nombre a estos claims con cuidado, por ejemplo mediante el espacio de nombres, para evitar colisiones con claims reservados u otros claims personalizados. Puede resultar difícil manejar dos claims con el mismo nombre que contienen información distinta.
Para obtener más información sobre los claims, consulta Claims de JSON Web Token.

​
Autenticar usuarios a través de una organización

Para autenticar a un usuario a través de una organización, se agrega un parámetro organization a una llamada al endpoint /authorize. A continuación, se muestran ejemplos de los tokens que se devuelven cuando un usuario inicia sesión a través de organizaciones.
De forma predeterminada, los tokens de ID y de acceso solo incluyen los ID de la organización. Sin embargo, puede configurar su inquilino para permitir el uso de nombres de organización en la Authentication API. Cuando se configura de este modo, los tokens de ID y de acceso contienen los claims org_id y org_name. Para obtener más información, consulte Usar nombres de organización en la Authentication API.

​
token de ID

En el siguiente ejemplo, ten en cuenta que https://marketplace/roles y https://namespace.exampleco.com/ son claims personalizados que se han añadido al token, mientras que los demás claims incluidos son estándar. 
{
  "https://marketplace/roles": [
    "marketplace-administrator"
  ],
  "https://namespace.exampleco.com": "my custom claim",
  "nickname": "firstName.lastName",
  "name": "firstName.lastName@email.com",
  "picture": "https://s.gravatar.com/avatar/638",
  "updated_at": "2021-03-23T11:34:14.566z",
  "email": "username@exampleco.com",
  "email_verified": true,
  "sub": "auth0|602c0dcab993d10073daf680",
  "org_id": "org_9ybsU1dN2dKfDkBi"
}

​
Token de acceso

{
  "iss": "https://exampleco.auth0.com/",
  "sub": "auth0|602c0dcab993d10073daf680",
  "aud": [
    "https://example-api/",
    "https://exampleco.auth0.com/userinfo"  
  ],
  "iat": 1616499255,
  "exp": 1616585655,
  "azp": "ENDmmAJsbwI1hOG1KPJddQ8LHjV6kLkV",
  "scope": "openid profile email",
  "org_id": "org_9ybsU1dN2dKfDkBi",
  "permissions": [
    "delete:stuff",
    "read:stuff",
    "write:stuff"  
  ]
}

​
Acceso entre máquinas a una organización

En los casos de uso entre máquinas, se agrega un parámetro organization a la solicitud de Client Credentials al endpoint /oauth/token para que una aplicación pueda obtener un token de acceso para sí misma y no para un usuario.
De forma predeterminada, los tokens de ID y de acceso solo incluyen los ID de la organización. Sin embargo, puede configurar su inquilino para permitir el uso de nombres de organización en la Authentication API. Cuando se configura de esta manera, los tokens de ID y de acceso contienen tanto las claims org_id como org_name. Para obtener más información, consulte Usar nombres de organización en la Authentication API.
La siguiente muestra de código es un ejemplo de token de acceso que se devuelve en casos de uso entre máquinas: 
{
  "iss": "https://exampleco.auth0.com/",
  "sub": "CS2MNgcX1VZFCJaEzfKw2VPAAS0gzhqP@clients",
  "aud": "https://example-api",
  "iat": 1727782196,
  "exp": 1727868596,
  "scope": "scope1 scope2",
  "org_id": "org_vIK75NKFvaozQsFy",
  "org_name": "acme",
  "gty": "client-credentials",
  "azp": "CS2MNgcX1VZFCJaEzfKw2VPAAS0gzhqP"
}

​
Validar tokens

Cuando se agrega el parámetro organization a una llamada al endpoint /authorize o al endpoint /oauth/token, los SDK de Auth0 validan automáticamente el claim org_id, que se devuelve como parte de cualquier token generado. Sin embargo, por motivos de seguridad, se debe realizar una validación adicional al recibir tokens.
Si ha configurado su inquilino para permitir el uso de nombres de organización en la Authentication API, los tokens de ID y de acceso contienen tanto los claims org_id como org_name. Si está presente, valide el claim org_name además de org_id para asegurarse de que los valores recibidos correspondan a una entidad de confianza.En general, usar ID de organización es el método preferido para validar tokens. Sin embargo, los nombres de organización pueden usarse si son más adecuados para su caso de uso. Para entender las posibles implicaciones de usar nombres de organización para validar tokens, consulte Usar nombres de organización en la Authentication API.
Para aplicaciones web: Si no se pasó ningún parámetro organization al endpoint /authorize, pero hay un claim org_id presente en el , su aplicación debe validar el claim para asegurarse de que el valor recibido sea el esperado o conocido y de que corresponda a una entidad en la que su aplicación confía, como un cliente de pago. Si el claim no puede validarse, la aplicación debe considerar el token no válido. Para las API: Si hay un claim org_id presente en el token de acceso, su API debe validar el claim para asegurarse de que el valor recibido sea el esperado o conocido y de que corresponda a una entidad en la que su aplicación confía, como un cliente de pago. Si el claim no puede validarse, la API debe considerar el token no válido. En particular:
  • Se debe comprobar el claim iss (emisor) para garantizar que el token fue emitido por Auth0.
  • Se debe comprobar el claim org_id para garantizar que sea un valor que la aplicación ya conoce. Esto puede validarse con una lista conocida de ID de organización, o bien comprobarse junto con la URL de la solicitud actual. Por ejemplo, el subdominio puede indicar qué organización debe usarse al validar el ID Token.
Normalmente, validar solo el emisor bastaría para garantizar que el token fue emitido por Auth0. Sin embargo, en el caso de las organizaciones, deben realizarse comprobaciones adicionales para asegurarse de que la organización dentro de su inquilino de Auth0 es la esperada. También es muy importante que sus servidores de API segmenten el acceso a los datos y recursos en función de org_id. Esto garantiza que solo se pueda acceder a la información de una organización determinada o modificarla cuando se reciba en el token de acceso el valor org_id correspondiente a esa organización.

​
Más información