Invocación del punto final de señal para OpenID Connect
En el flujo de código de autorización de OpenID Connect, un cliente utiliza el punto final de señal para obtener una señal de ID, una señal de acceso y una señal de renovación.
Antes de empezar
Acerca de esta tarea
El punto final de señal acepta una solicitud del cliente que incluye un código de autorización emitido por el punto final de autorización al cliente. Cuando se valida el código de autorización, las señales correspondientes se devuelven en una respuesta al cliente.
El punto final de señal no se utiliza en el flujo implícito de OpenID Connect.
Un servidor de Liberty con OpenID Connect habilitado tiene acceso al punto final de la señal de OpenID Connect en el siguiente URL:
https://server.example.com:443/oidc/endpoint/<provider_name>/token
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
Resultados
Cuando el proveedor de OpenID Connect valida la solicitud de señal que recibe del cliente, el proveedor de OpenID Connect devuelve una respuesta HTTP 200 al cliente con un objeto JSON en formato application/json. La respuesta incluye la señal de ID, la señal de acceso y la señal de renovación, junto con los siguientes parámetros adicionales:
- token_type: Tipo de señal OAuth 2.0. Para OpenID Connect, este valor es Bearer.
- expires_in: Hora de caducidad de la señal de acceso en segundos desde que se generó la respuesta.
Todas las respuestas del punto final de señal que contienen señales, secretos u otra información confidencial tienen el valor de cabecera Cache-Control establecido en no-store y el valor de cabecera Pragma establecido en no-cache.
.Ejemplo
A continuación, se muestra una solicitud de ejemplo:
POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
A continuación, se muestra una respuesta de ejemplo:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJ ... zcifQ.ewo ... NzAKfQ.ggW8h ... Mzqg"
}