Claims y permisos de Summit Auth

Los claims disponibles dependen de los scopes solicitados y de los datos y accesos del usuario.

Access token

Claims	Origen o condición
sub	Identificador del usuario.
given_name, family_name, middle_name, nickname, profile, picture, website, zoneinfo, locale, preferred_username	Perfil del usuario con scope profile.
email, email_verified	Cuenta del usuario.
display_name	Perfil del usuario.
summit_email	true si el dominio del correo coincide con el dominio corporativo de alguna organización activa del usuario; de lo contrario, false.
sid	Identificador de sesión.
role	Un claim por cada rol Identity asignado.
plan, product_access, product_plan	Accesos por producto otorgados directamente al usuario (no a través de una organización).
organization_product_access	Accesos por producto otorgados a través de la organización activa (organization_id). Puede coexistir con product_access si el usuario tiene el mismo producto por ambas vías.
organization_id, tenant_id, organization_role	Solo cuando el usuario seleccionó una organización.
groups	Grupos de producto habilitados para la aplicación cliente y a los que el usuario tiene acceso. Un claim por grupo.

Un producto puede marcarse como exclusivo para organizaciones. En ese caso, un acceso otorgado directamente al usuario nunca aparece en product_access; solo cuenta el acceso obtenido a través de una organización (organization_product_access). Consulta Acceso a productos para el detalle completo.

groups se emite como valores repetidos en el access token y como arreglo de cadenas en UserInfo. No se incluye en el ID token ni en tokens de Client Credentials. Consulta Grupos de productos para conocer su resolución.

Id token

Claims	Requisito
sub, sid	Sin scope adicional.
given_name, family_name, middle_name, nickname, profile, picture, website, zoneinfo, locale, preferred_username, gender, birthdate	Scope profile.
email, email_verified	Scope email; en la práctica suelen estar presentes.
display_name, plan, summit_email	Scope profile.
phone_number, phone_number_verified	Scope phone, obligatorio sin excepciones.

role y los claims organization_* solo se incluyen en el access token, nunca en el id token.

Respuesta de UserInfo

/connect/userinfo devuelve el perfil del usuario junto con sus roles, permisos y accesos. La respuesta es un objeto JSON; los valores que dependen del scope o de datos del usuario se omiten cuando no aplican:

GET /connect/userinfo
Authorization: Bearer <ACCESS_TOKEN>

{
  "sub": "USER_ID",
  "email": "user@example.com",
  "email_verified": true,
  "phone_number": "+593900000000",
  "phone_number_verified": true,
  "name": "user@example.com",
  "display_name": "Ana Torres",
  "plan": "summit_ai:pro",
  "summit_email": true,
  "organization_id": "11111111-2222-3333-4444-555555555555",
  "organization_role": "Admin",
  "tenant_id": "11111111-2222-3333-4444-555555555555",
  "role": ["Member"],
  "permission": [
    "billing.subscriptions.read",
    "organizations.members.read"
  ],
  "organization_permission": [
    "org.members.read",
    "org.invitations.manage"
  ],
  "product_access": ["climbedge:pro"],
  "product_plan": ["climbedge:pro:active"],
  "organization_product_access": ["summit_ai:business"],
  "groups": ["beta", "early_access"],
  "has_required_product_access": true
}

Campos por scope

Los claims de perfil (email, email_verified, name, display_name, plan, summit_email, organization_id, organization_role, tenant_id) solo se incluyen cuando el access token tiene el scope correspondiente:

Scope	Claims incluidos
email	email, email_verified.
phone	phone_number, phone_number_verified (si el usuario tiene teléfono).
profile	name, display_name, plan, summit_email y el contexto de organización (organization_id, organization_role, tenant_id) cuando aplica.
Cualquiera	sub siempre; role, permission, organization_permission, product_access, product_plan, organization_product_access, groups y has_required_product_access cuando aplican.

role, permission, organization_permission, product_access, product_plan, organization_product_access y groups se devuelven como arreglos y se omiten si están vacíos.

Permisos mediante UserInfo

Desde el 4 de agosto de 2026, permission y organization_permission ya no se incluyen en los tokens para evitar que su tamaño crezca sin límite. Se calculan al recibir la solicitud de /connect/userinfo y respetan el scope y la organización activa. Almacena el resultado durante la vigencia del access token en lugar de consultar UserInfo en cada request.

Mapa interno de construcción

AuthorizationController.BuildUserPrincipalAsync delega cada grupo de claims:

Método	Responsabilidad
AddProfileClaimsAsync y AddPhoneClaims	Perfil OIDC, correo y teléfono.
AddUserRoleClaimsAsync	Roles Identity.
AddRoleClaimsAsync y AddUserPermissionClaimsAsync	Permisos generales filtrados por definición activa y scope.
AddProductAccessClaimsAsync	Acceso personal y organizacional a productos.
AddOrganizationContextClaimsAsync	Organización, tenant, rol y permisos organizacionales.
AddProductGroupClaimsAsync	Grupos de producto habilitados para la aplicación cliente (groups).
AddSummitEmailClaimAsync	Coincidencia del dominio corporativo.
CopySessionClaim	Identificador sid.

El destino final se resuelve desde ClaimDefinitions y reglas específicas de scope. phone_number y phone_number_verified requieren phone.

Separación por procedencia

ProductAccess contiene el acceso efectivo, pero la procedencia vive en ProductAccessAssignment.OrganizationId. Para cada producto se elige la asignación efectiva priorizando estado activo y luego expiración más lejana.

• product_access, product_plan y plan representan acceso personal.
• organization_product_access representa acceso procedente de la organization_id activa.

Un otorgamiento directo creado por la API interna no tiene una asignación de suscripción y se considera personal, excepto cuando el producto exige organización y por tanto no puede hacerse efectivo.

has_required_product_access en UserInfo

Si tu aplicación tiene configurado un requisito de acceso a producto (ver Acceso a productos), la respuesta de /connect/userinfo incluye el booleano has_required_product_access. Úsalo para mostrar un mensaje o un flujo de upgrade en la propia aplicación sin depender de que /connect/authorize haya denegado la solicitud.

Grupos de producto (groups)

Un grupo de producto es un agrupador de autorización que pertenece a un producto y solo se expone a las aplicaciones cliente vinculadas explícitamente. Permite que una aplicación cliente sepa, mediante el claim groups, a qué subconjuntos de usuarios de un producto está autorizando, sin necesidad de listar cada usuario individualmente.

Un grupo se emite en el access token y en UserInfo solo cuando se cumplen todas estas condiciones:

• el producto al que pertenece el grupo está activo y el usuario tiene acceso vigente a ese producto;
• la aplicación cliente autenticada está vinculada al producto y al grupo;
• el usuario obtiene el grupo por al menos una de estas vías:

Vía	Descripción
Personal	Asignación directa del grupo al usuario.
Organización	Asignación del grupo a la organización activa del usuario.
Miembro de organización	Asignación del grupo a la membresía del usuario en la organización activa.

Un grupo asignado a un producto exclusivo para organizaciones no se emite desde una vía personal; requiere la organización activa o la membresía correspondiente.

En el access token el claim aparece una vez por grupo (groups con un valor por claim); en UserInfo se devuelve como un arreglo ordenado de claves. Cuando ninguna vía aplica, el claim no se emite.