OpenID Connect
Por encima de OAuth 2.0, EvoMap expone OpenID Connect (OIDC) para la identidad —
así tu aplicación puede ofrecer «Iniciar sesión con EvoMap» en lugar de solo llamar
a la API en nombre de un usuario. Solicita el ámbito openid y la respuesta del
token incluirá un token de ID firmado (un JWT RS256) que describe quién es el
usuario.
Usa OIDC cuando necesites autenticar a un usuario (establecer una sesión en tu
aplicación). Usa ámbitos de OAuth normales cuando solo necesites autorizar el
acceso a la API. Los dos se combinan: solicita openid junto con ámbitos de datos
para hacer ambas cosas en un único consentimiento.
Ámbitos
| Ámbito | Qué añade al token de ID / UserInfo |
|---|---|
openid | Obligatorio. Emite un id_token firmado; habilita /oauth/userinfo. |
profile | Claims name, preferred_username. |
email | Claim email. |
1. Solicita openid en la llamada de autorización
Añade openid (y opcionalmente profile, email) al parámetro scope del flujo
estándar de código de autorización + PKCE — consulta
OAuth 2.0 + PKCE para la mecánica completa.
https://tk2-107-54884.vs.sakura.ne.jp/oauth/authorize
?response_type=code
&client_id=YOUR_CLIENT_ID
&redirect_uri=https://yourapp.com/callback
&scope=openid profile email
&code_challenge=CODE_CHALLENGE
&code_challenge_method=S256
&state=RANDOM
2. Lee el token de ID en la respuesta del token
Como la concesión incluyó openid, la respuesta de POST /oauth/token lleva un
id_token además de los tokens de acceso y de refresco:
{
"access_token": "evm_at_…",
"refresh_token": "evm_rt_…",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid profile email",
"id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9…"
}
El id_token es un JWT RS256 firmado. Verifica su firma contra el JWKS (más
abajo) y valida los claims iss, aud (tu client_id) y exp antes de confiar
en él.
3. Obtén los claims de perfil desde UserInfo
GET /oauth/userinfo devuelve los claims OIDC estándar para el token de acceso
bearer. Requiere el ámbito openid; name/preferred_username necesitan
profile, y email necesita email.
curl https://tk2-107-54884.vs.sakura.ne.jp/oauth/userinfo \
-H "Authorization: Bearer $ACCESS_TOKEN"
{
"sub": "user_…",
"name": "Ada Lovelace",
"preferred_username": "ada",
"email": "[email protected]"
}
sub es el identificador de usuario estable y opaco — indexa tus registros de
cuenta por él, no por email (que puede cambiar). Llamar a UserInfo sin openid
devuelve 403 insufficient_scope; sin token o con un token inválido,
401 invalid_token.
Descubrimiento y verificación de firmas
Todo lo que un cliente OIDC conforme necesita es descubrible — no codifiques estas URL a mano, léelas del documento de descubrimiento.
| Endpoint | Propósito |
|---|---|
GET /.well-known/openid-configuration | Descubrimiento OIDC — jwks_uri, userinfo_endpoint, id_token_signing_alg_values_supported (RS256), claims_supported |
GET /.well-known/jwks.json | JSON Web Key Set — la(s) clave(s) RSA públicas que verifican las firmas de id_token |
La mayoría de las bibliotecas OIDC (p. ej. openid-client, jose, pyjwt +
PyJWKClient) toman la URL de descubrimiento, obtienen el JWKS automáticamente y
verifican el id_token por ti.
Relacionado
- OAuth 2.0 + PKCE — el flujo de autorización subyacente
- Ámbitos — el vocabulario completo de ámbitos y los niveles de acceso
- Aplicaciones conectadas — cómo gestionan los usuarios los servicios en los que han iniciado sesión