OpenID Connect: qué es, protocolo de autenticación y autorización

¿Qué es OpenID Connect?

OpenID Connect (OIDC) es un protocolo de autenticación abierto construido como una extensión sobre OAuth 2.0. Estandariza lo que faltaba en OAuth 2.0: la verificación de identidad del usuario. Si OAuth 2.0 responde a la pregunta “¿qué aplicación tiene acceso?”, entonces OIDC responde “¿quién es exactamente este usuario?”.

El protocolo utiliza un ID Token — un JSON Web Token (JWT) que contiene un conjunto de claims: un identificador de sujeto único, email, nombre, avatar, marcas de tiempo de emisión y caducidad. La aplicación cliente puede verificar criptográficamente el ID Token — el servidor firma el token con RS256 o ES256, y el cliente comprueba la firma contra la clave pública obtenida a través del endpoint JWKS.

Según Auth0, 2025, más del 78% de las aplicaciones móviles que utilizan autenticación de terceros emplean OIDC a través de Google Sign-In o Sign in with Apple. Esto convierte al protocolo en el estándar de facto para el inicio de sesión social y la autenticación empresarial.

Cómo funciona OpenID Connect

OpenID Connect define varios flujos (flows) según el tipo de cliente. Para aplicaciones móviles, el estándar es el Authorization Code Flow con Proof Key for Code Exchange (PKCE) — proporciona seguridad incluso sin un client secret en el dispositivo.

Identity Provider y su función

Un Identity Provider (IdP) es un servidor que autentica usuarios y emite tokens. En el ecosistema OIDC, el IdP proporciona dos endpoints clave: el Authorization Endpoint para el inicio de sesión del usuario y el Token Endpoint para intercambiar el código por tokens. El cliente descubre las direcciones de estos endpoints a través de la Discovery URL — la ruta estándar /.well-known/openid-configuration, que devuelve un documento JSON con toda la configuración del proveedor.

Cada IdP publica su JWKS (JSON Web Key Set) — un conjunto de claves públicas para verificar la firma del ID Token. El cliente almacena en caché estas claves y las utiliza para verificar cada token recibido sin contactar al servidor.

Authorization Code Flow con PKCE

El Authorization Code Flow es un proceso de tres pasos. Primero, la aplicación móvil genera un code verifier (una cadena aleatoria de 43–128 caracteres) y su hash — el code challenge. La aplicación abre un navegador o WebView con una URL que contiene el client_id, redirect_uri, scope (openid profile email) y code challenge. El usuario introduce sus credenciales en la página del IdP y confirma el consentimiento. El IdP redirige el navegador de vuelta a la aplicación con un authorization code.

En el segundo paso, la aplicación envía el authorization code, code verifier y client_id al Token Endpoint del servidor. El servidor verifica el code verifier contra el code challenge almacenado y devuelve un ID Token, Access Token y opcionalmente un Refresh Token. En el tercer paso, la aplicación verifica el ID Token: valida la firma contra JWKS, comprueba el issuer (iss), audience (aud) y el tiempo de caducidad (exp). Si la verificación es exitosa, el usuario se considera autenticado.

PKCE (Proof Key for Code Exchange) elimina una vulnerabilidad inherente al Authorization Code Flow estándar en clientes públicos. Dado que una aplicación móvil no puede almacenar de forma segura un client secret, un atacante que intercepte el authorization code podría intercambiarlo por tokens. El code verifier resuelve este problema: incluso si el código es interceptado, sin el code verifier original el intercambio es imposible. OAuth Security Best Practices (RFC 9700) exigen PKCE para todos los clientes públicos, incluidas las aplicaciones móviles.

ID Token y Access Token

OpenID Connect devuelve dos tokens fundamentalmente diferentes: el ID Token y el Access Token. El ID Token es siempre un JWT que el cliente puede leer y verificar por sí mismo. Contiene información del usuario y se utiliza para la autenticación, no para el acceso a la API.

Estructura del ID Token

El ID Token consta de un header, payload y signature, codificados en Base64 y separados por puntos. El header contiene alg (algoritmo de firma) y kid (identificador de clave). El payload incluye claims obligatorios: iss (issuer), sub (subject — ID único del usuario), aud (audience — identificador del cliente), exp (expiration), iat (issued at). Los claims opcionales incluyen name, email, picture, locale.

Ejemplo de un payload de ID Token decodificado de Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

El Access Token es un token opaco (cadena arbitraria) o JWT que el cliente pasa en las solicitudes a la API. A diferencia del ID Token, el access token no está diseñado para ser leído por el cliente — su formato y contenido solo son conocidos por el servidor de recursos y el servidor de autorización. El Access Token tiene un scope — una restricción de permisos — y una vida útil corta, normalmente de 15–60 minutos.

Diferencias entre OpenID Connect y OAuth 2.0

OAuth 2.0 es un marco de autorización que define cómo una aplicación obtiene acceso a los recursos del usuario. OpenID Connect es una extensión que añade autenticación a este proceso. La diferencia clave: OAuth 2.0 no define un formato de token y no proporciona a la aplicación una forma de saber quién realizó la solicitud.

Cuándo elegir OpenID Connect

OpenID Connect es necesario cuando la aplicación necesita identificar al usuario, no solo obtener acceso a sus datos. Si utiliza “Iniciar sesión con Google” o “Iniciar sesión con Apple” — eso es OIDC. Si su aplicación llama a una API de terceros en nombre del usuario sin necesidad de conocer su identidad — OAuth 2.0 puro es suficiente. Para sistemas empresariales con Single Sign-On (SSO), la elección es clara: solo OpenID Connect, ya que proporciona cierre de sesión estandarizado y gestión de sesiones.

Implementación de OpenID Connect en aplicaciones móviles

La integración de OpenID Connect en una aplicación móvil requiere elegir la biblioteca adecuada y configurar correctamente el flujo. Para Android, use el credential manager (AndroidX Credentials) o la biblioteca AppAuth. Para iOS, use el framework AuthenticationServices con ASWebAuthenticationSession.

Ejemplo de código en Kotlin (Android)

A continuación se muestra un ejemplo de inicio del Authorization Code Flow con la biblioteca AppAuth-Android. La aplicación crea una solicitud de autorización, abre un navegador para el inicio de sesión del usuario y procesa el callback con los tokens.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Ejemplo de código en Swift (iOS)

El ASWebAuthenticationSession de Apple proporciona un navegador integrado para el flujo OIDC con soporte SSO a través de iCloud Keychain. La sesión se inicia con la URL de autorización, y el callback se maneja a través de un completion handler.

Al elegir una biblioteca para OpenID Connect, considere el soporte PKCE integrado: AppAuth-Android y AppAuth-iOS admiten PKCE de forma predeterminada. Firebase Authentication utiliza OIDC internamente para Google Sign-In, Sign in with Apple y Microsoft — el desarrollador no necesita implementar el flujo manualmente. Para sistemas empresariales con un IdP personalizado (por ejemplo, Keycloak u Okta), AppAuth sigue siendo la opción estándar con control total sobre la configuración y el manejo de errores.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()