> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Descubre cómo funcionan los tokens con la funcionalidad Organizations de Auth0 y cómo autenticar a los usuarios que pertenecen a una organización.

# Trabajar con tokens y organizaciones

<Card title="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](https://auth0.com/pricing).
</Card>

La mayoría de los tokens de identidad (ID) y los <Tooltip tip="Token de acceso: Credencial de autorización, en forma de cadena opaca o JWT, utilizada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=access+tokens">tokens de acceso</Tooltip> que devuelve Auth0 son <Tooltip tip="Token de acceso: Credencial de autorización, en forma de cadena opaca o JWT, utilizada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=JSON+Web+Tokens">JSON Web Tokens</Tooltip> (JWT) que contienen diversos claims, es decir, fragmentos de información declarados sobre un sujeto. Por ejemplo, un [token de ID](/es/docs/secure/tokens/id-tokens) (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](https://tools.ietf.org/html/rfc7519) para garantizar la interoperabilidad con aplicaciones de terceros o externas. Los claims estándar de [OpenID Connect (OIDC)](/es/docs/authenticate/protocols/openid-connect-protocol) 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](/es/docs/secure/tokens/json-web-tokens/create-custom-claims), 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](/es/docs/secure/tokens/json-web-tokens/json-web-token-claims).

<div id="authenticate-users-through-an-organization">
  ## Autenticar usuarios a través de una organización
</div>

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/es/docs/manage-users/organizations/configure-organizations/use-org-name-authentication-api).
</Callout>

<div id="id-token">
  ### token de ID
</div>

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.

```json lines theme={null}
{
  "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"
}
```

<div id="access-token">
  ### Token de acceso
</div>

```json lines theme={null}
{
  "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"  
  ]
}
```

<div id="machine-to-machine-access-to-an-organization">
  ## Acceso entre máquinas a una organización
</div>

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/es/docs/manage-users/organizations/configure-organizations/use-org-name-authentication-api).
</Callout>

La siguiente muestra de código es un ejemplo de token de acceso que se devuelve en casos de uso entre máquinas:

```json lines theme={null}
{
  "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"
}
```

<div id="validate-tokens">
  ## Validar tokens
</div>

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/es/docs/manage-users/organizations/configure-organizations/use-org-name-authentication-api).
</Callout>

**Para aplicaciones web:**

Si no se pasó ningún parámetro `organization` al endpoint `/authorize`, pero hay un claim `org_id` presente en el <Tooltip tip="ID Token: Credencial destinada al propio cliente, no para acceder a un recurso." cta="Ver glosario" href="/es/docs/glossary?term=ID+token">token de ID</Tooltip>, 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.

<div id="learn-more">
  ## Más información
</div>

* [Comprenda cómo funcionan las Organizations de Auth0](/es/docs/manage-users/organizations/organizations-overview)
* [Cree su primera organización](/es/docs/manage-users/organizations/create-first-organization)
* [Desarrollo personalizado con Organizations](/es/docs/manage-users/organizations/custom-development)
* [Configure las Organizations](/es/docs/manage-users/organizations/configure-organizations)