AUTH4US
Solicitar demo

Protocolos

OpenID Connect y OAuth 2.0, con lo justo y lo seguro.

Cuatro grants registrados, un solo tipo de respuesta y PKCE S256 obligatorio para clientes públicos. Lo que no está aquí, no está registrado.

Verificado en CI de integraciónVerificado en el productoVerificado en el producto
  1. Descubrir
  2. Autorizar
  3. Probar
  4. Verificar
  5. Consentir
  6. Emitir
  7. Sesión
  8. Revocar

Seis endpoints, petición y respuesta.

Desliza, usa las flechas del teclado o los controles. Los valores son sintéticos y no funcionan contra ningún servidor.

Authorize

/connect/authorizeNavegador con sesión
GET /connect/authorize?response_type=code
  &client_id=portal-demo
  &redirect_uri=https://portal.example.com/cb
  &scope=openid profile
  &code_challenge=<S256>&code_challenge_method=S256
302 Location: https://portal.example.com/cb
  ?code=<código de un solo uso>
  &state=<el mismo state>

Sin sesión, redirige a iniciar sesión. Sin consentimiento activo para los scopes, responde consent_required.

1 de 6

Código de autorización con PKCE

  1. Un valor aleatorio que nunca sale del límite de la aplicación hasta el intercambio final.

    code_verifier = «ejemplo-sintético-no-válido»

  2. Solo el hash del verificador viaja. AUTH4US rechaza el método plain.

    code_challenge_method=S256

  3. /connect/authorize con client_id, redirect_uri registrado de forma exacta y el desafío.

    Verificado multi-nodo

  4. Un código de autorización de cinco minutos regresa al redirect_uri registrado.

    Verificado en el producto

  5. /connect/token compara el hash del verificador con el desafío guardado. Sin verificador, no hay tokens.

    Verificado en el producto

  6. Access token e ID token firmados con ES256. En el navegador, el access token vive solo en memoria.

    Código completo
El verificador permanece en la aplicación; solo el desafío viaja; el verificador desbloquea el intercambio.

Servicio a servicio, con el secreto donde debe estar.

Client credentials es para clientes confidenciales del lado del servidor. Nunca enseñamos a guardar ese secreto en un navegador.

Verificado multi-nodoVerificado en CI de integración
Client credentials
  1. Servicio A → AUTH4US: grant_type=client_credentials + autenticación del cliente
  2. AUTH4US → Servicio A: Access token con alcance limitado
  3. Servicio A → API del servicio B: Authorization: Bearer <token>
  4. API del servicio B → AUTH4US: Introspección o verificación con JWKS
  5. AUTH4US → API del servicio B: active: true, alcance

Veámoslo con tus aplicaciones.

Una demostración con datos sintéticos: tus flujos, tus métodos de entrada y tu modelo de tenants.

Solicitar demoExplorar AUTH4US