Invocación del punto final de introspección para OpenID Connect

El punto final de introspección permite a las cabeceras de las señales de acceso solicitar un conjunto de metadatos sobre una señal de acceso desde el proveedor de OpenID Connect que ha emitido la señal de acceso. La señal de acceso debe haberse obtenido mediante la autenticación de OAuth o OpenID Connect.

Antes de empezar

Cuando un servicio de recursos o una aplicación cliente invoca el punto final de introspección, debe registrarse como un cliente OAuth 2.0 normal en el servidor de OpenID Connect. Los metadatos del cliente registrado deben incluir el atributo introspectTokens = true.

Acerca de esta tarea

La información contenida en las señales de acceso que se utilizan en OpenID Connect y OAuth 2.0 es opaca para los clientes. Esto permite a los clientes o recursos protegidos tomar decisiones de autorización basadas en los metadatos que devuelve el proveedor de OpenID Connect sobre de la señal de acceso.

Un servidor de Liberty con OpenID Connect habilitado tiene acceso al punto final de introspección de OpenID Connect en el siguiente URL:

 https://server.example.com:443/oidc/endpoint/<provider_name>/introspect
Evite problemas: Si está utilizando un proxy de salida, tenga en cuenta que la RP de OpenID Connect no proporciona un medio de direccionar las solicitudes a través de un host de proxy de forma automática.

Si tiene que utilizar un proxy para acceder al proveedor de OpenID Connect (OP), el valor que especifique en cualquier propiedad de URL relacionada con OP tiene que contener el host de proxy y el puerto, no el host y el puerto externos de OP.

En la mayoría de los casos, se puede sustituir el host y el puerto de OP con el host y el puerto del proxy. El URL que especifique tiene que ser visible a la RP y al cliente (navegador o aplicación). Para obtener pautas adicionales sobre cómo determinar el URL que hay que usar, póngase en contacto con el administrador del proxy.

En este ejemplo, el cliente espera que el puerto SSL esté establecido en 443.

Procedimiento

  1. Configure la autenticación de cliente con el ID de cliente y la contraseña de un cliente de OpenID Connect registrado en la cabecera de autorización básica HTTP de una solicitud GET o POST. El ID de cliente y la contraseña se codifican utilizando el algoritmo de codificación application/x-www-form-urlencoded. El ID de cliente codificado se utiliza como el nombre de usuario y la contraseña codificada se utiliza como la contraseña.
  2. Incluya el valor de serie de la señal de acceso como un parámetro en la solicitud GET o POST al punto final de introspección.
  3. Envíe la solicitud GET o POST al URL de punto final de introspección.

Resultados

Después de completar estos pasos, tiene una solicitud HTTP válida que se envía al punto final de introspección como se muestra en la sección Ejemplos.

Para ver las solicitudes válidas, el punto final de introspección devuelve una respuesta HTTP 200 con un objeto JSON en formato application/json que incluye la siguiente información, dependiendo de si la señal de acceso está activa o ha caducado.

Cuando la señal de acceso está activa, el punto final devuelve active:true, así como la siguiente información adicional en el objeto JSON:

  • active: Indicador booleano de si la señal de acceso está activa.
  • client_id: El identificador de cliente de OpenID Connect Client que ha solicitado la señal de acceso.
  • sub: El propietario del recurso que está autorizado al señal de acceso.
  • scopeLista separada por comas de ámbitos que están asociados a la señal de acceso.
  • iat: Indicación de fecha y hora de entero, medida en segundos, desde el 1 de enero de 1970 UTC, que indica cuando se emitió la señal de acceso.
  • exp: Indicación de fecha y hora de entero, medido en segundos, desde el 1 de enero de 1970 UTC, que indica cuándo caducará la señal de acceso.
  • realmName: Nombre de reino del propietario del recurso.
  • uniqueSecurityName: Nombre de seguridad exclusivo del propietario del recurso.
  • tokenType: Tipo de señal de acceso. Para OpenID Connect, este valor es Bearer.
  • grant_type: Serie que indica el tipo de otorgamiento que ha generado la señal de acceso. Los valores posibles son: authorization_code, password, refresh_token, client_credentials, resource_owner, implicit y urn:ietf:params:oauth:grant-type:jwt-bearer.

Si la señal de acceso ha caducado, pero la autenticación proporcionada es válida, o si la señal de acceso proporcionada es del tipo incorrecto, el punto final devuelve active:false en el objeto JSON.

Nota: Para que un servicio de recursos o un cliente pueda realizar la introspección señal de acceso, el servicio de recursos o el cliente debe registrarse como un cliente en el proveedor de OpenID Connect, y los metadatos del cliente deben tener introspect_tokens establecido en true.

Ejemplo

A continuación, se muestran ejemplos de una señal de acceso activa y caducada junto con una solicitud.

A continuación, se muestra una solicitud de ejemplo:

  POST /register HTTP/1.1
 Accept: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
     token=SOYleDziTitHeKcodp6vqEmRwKPjz3lFZTcsQtVC

Una respuesta de ejemplo para una señal de acceso activa:

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
{  
   "exp"                : 1415307710,
   "realmName"          : "BasicRealm",
   "sub"                : "testuser",
   "scope"              : "openid scope2 scope1",
   "grant_type"         : "authorization_code",
   "uniqueSecurityName" : "testuser",
   "active"             : true,
   "token_type"         : "Bearer",
   "client_id"          : "pclient01",
   "iat"                : 1415307700
}

Respuesta de ejemplo para una señal de acceso caducada:

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
 {
     "active":"false"
 }

Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: twlp_oidc_introspection_endpoint.html