Inicio de sesión con Sangho (OAuth2)
«Iniciar sesión con Sangho» permite a su plataforma autenticar a sus usuarios mediante su cuenta de Sangho existente, sin manejar nunca su contraseña, igual que «Iniciar sesión con Google». Sangho actúa como proveedor de identidad (código de autorización OAuth2 + PKCE obligatorio), distinto de las claves API pk_/sk_ que autentican las llamadas de su servidor a la API de Sangho.
Host canónico: accounts.sangho.com. Las integraciones ya configuradas en dash.sangho.com/o/… siguen funcionando (retrocompatibilidad), pero toda integración nueva debe utilizar accounts.sangho.com.
1. Crear un cliente OAuth
Un cliente OAuth se crea en autoservicio desde la pestaña Claves API de su panel de Sangho: nombre, descripción, URI de redirección. El client_secret (SANGHO_SECRET en su plataforma) solo se muestra una vez, en el momento de la creación: guárdelo de inmediato en su gestor de secretos.
Un cliente creado en autoservicio nunca es «de confianza a priori»: la pantalla de consentimiento de Sangho se muestra siempre que un usuario nuevo inicia sesión. Esto es lo esperado, no un error de configuración.
2. Flujo de autorización (PKCE obligatorio)
| Paso | Endpoint | Descripción |
|---|---|---|
| 1. Redirigir al usuario | GET /o/authorize/ | Con client_id, redirect_uri, response_type=code, scope, state, code_challenge, code_challenge_method=S256 |
| 2. Consentimiento | — | El usuario inicia sesión en Sangho (si es necesario) y después autoriza su aplicación |
| 3. Callback | su redirect_uri | Sangho redirige con ?code=…&state=… (compruebe state frente a CSRF) |
| 4. Intercambiar el código | POST /o/token/ | grant_type=authorization_code, code, redirect_uri, client_id, code_verifier |
| 5. Renovar | POST /o/token/ | grant_type=refresh_token, refresh_token, client_id |
| 6. Revocar | POST /o/revoke_token/ | token, client_id — invalida un access o refresh token |
PKCE (code_challenge/code_verifier, método S256) es obligatorio, incluso para un cliente confidencial del lado del servidor: la solicitud se rechaza sin él. Los access tokens caducan a la 1 hora y los refresh tokens a los 30 días.
3. Scopes y perfil de usuario
| Scope | Claims devueltos por /o/userinfo/ |
|---|---|
| profile | name, given_name, family_name, picture |
| email, email_verified |
GET /o/userinfo/ (con Authorization: Bearer <access_token>) devuelve siempre sub: un identificador estable y opaco (UUID), nunca la dirección de correo electrónico. Utilícelo como clave de identidad permanente en su plataforma, ya que el correo electrónico puede cambiar.
4. Revocación y suspensión
El propietario de un cliente OAuth puede suspender su cliente desde el panel (suspend/activate): ya no se acepta ninguna autorización nueva ni intercambio de tokens para ese client_id, pero un access token ya emitido sigue siendo válido hasta su caducidad natural (sin revocación retroactiva inmediata), como en la mayoría de los proveedores OAuth2.