Organizaciones en Summit Auth
Summit Auth determina la organización activa durante /connect/authorize. Esta selección controla los claims organization_id, tenant_id, organization_role y los permisos organizacionales disponibles mediante UserInfo.
organization_id vs. tenant_id
Sección titulada «organization_id vs. tenant_id»Son dos identificadores distintos que hoy siempre viajan juntos, pero responden preguntas diferentes:
organization_ididentifica la organización comercial: la cuenta que tiene miembros, un plan de facturación, un dominio de correo, etc. Es el identificador “de negocio” — el que ves en/api/organizations/{id}y en la administración de organizaciones.tenant_ididentifica el límite técnico de aislamiento de datos. Es el que usan internamente los registros propios de una organización (suscripciones, asignaciones de acceso, membresías) para separar los datos de una organización de los de otra dentro de la misma base de datos compartida.
Cada organización es dueña de exactamente un tenant, así que en la práctica ambos valores siempre coinciden hoy. Aun así, tu aplicación no debería asumir que son intercambiables: usa organization_id para identificar la cuenta ante el usuario o tus propias APIs de negocio, y trata tenant_id como un detalle de aislamiento de datos, no como el identificador “canónico” de la organización.
Ambos claims se emiten siempre juntos — nunca uno sin el otro — y solo cuando el usuario tiene una membresía activa en una organización activa seleccionada para esa sesión.
Resolución automática
Sección titulada «Resolución automática»Cuando la solicitud no incluye organization_id:
- Sin organizaciones: el login continúa normalmente, sin claims organizacionales.
- Con una organización: se selecciona automáticamente.
- Con varias y una preferencia previa: se conserva la organización o el modo personal elegido anteriormente.
- Con varias y sin preferencia: el usuario pasa por
/Organizations/Select, donde elige una organización o el modo personal.
Después de la selección, Summit Auth vuelve automáticamente a /connect/authorize con los parámetros originales. La aplicación cliente solo debe esperar la respuesta final del flujo.
Elegir el modo personal también se recuerda para futuros inicios de sesión. Los tokens se emiten sin claims organizacionales.
Autorización interna
Sección titulada «Autorización interna»OrganizationAccessService.GetAccessAsync es la fuente de verdad para el
acceso a una organización. Devuelve null cuando la organización o la membresía
no están activas. Cuando existe acceso, devuelve el rol organizacional y sus
permisos actuales.
OrganizationManagementService utiliza ese resultado para miembros, roles,
invitaciones y puestos de suscripciones. Los permisos se consultan en la base de
datos; no se confía en una copia incluida en el token.
Los roles organizacionales son administrables por organización. Un permiso solo puede asignarse a un rol cuando su definición activa lo permite explícitamente; el prefijo de su nombre no concede esa capacidad. Las invitaciones se usan para incorporar miembros y permanecen sujetas a la validación de organización y membresía activa antes de conceder acceso.
APIs de lectura
Sección titulada «APIs de lectura»GET /api/organizations/{id}GET /api/organizations/{id}/productsGET /api/organizations/{id}/products/{subscriptionId}/assignmentsAuthorization: Bearer <ACCESS_TOKEN>La primera operación devuelve datos de la organización junto con rol y permisos del caller. La segunda devuelve suscripciones con producto, plan, funcionalidades y uso de puestos. La tercera devuelve asignaciones por miembro; un caller sin capacidad administrativa solo ve su propia fila.
Una organización inexistente y una organización ajena devuelven el mismo 404.
Consulta APIs internas para el contrato JSON completo.
Solicitar una organización
Sección titulada «Solicitar una organización»La aplicación puede incluir el identificador para evitar la pantalla de selección:
GET /connect/authorize ?client_id=YOUR_CLIENT_ID &redirect_uri=https://app.example.com/auth/callback &response_type=code &scope=openid profile email &organization_id=<ORGANIZATION_GUID>El servidor verifica que el usuario sea miembro activo. Si no lo es, el login continúa sin claims de organización; no se rechaza toda la solicitud.