Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
El punto final del emisor del token
El punto final del token OAuth/oauth2/token
los tokens JSON web ()JWTs. Estos tokens son el resultado final de la autenticación con un grupo de usuarios. Contienen información sobre el usuario (token de ID), su nivel de acceso (token de acceso) y su derecho a conservar la sesión en la que ha iniciado sesión (token de actualización). Las bibliotecas de partes dependientes de OpenID Connect (OIDC) gestionan las solicitudes y las cargas útiles de respuesta desde este punto final. Los tokens proporcionan una prueba de autenticación verificable, información de perfil y un mecanismo de acceso a los sistemas de back-end.
El servidor de autorización de su grupo de usuarios OAuth 2.0 emite tokens JSON web (JWTs) desde el punto final del token para los siguientes tipos de sesiones:
-
Los usuarios que han completado una solicitud de concesión de un código de autorización. Al canjear correctamente un código, se obtienen tokens de ID, acceso y actualización.
-
Machine-to-machine Sesiones (M2M) que han completado una concesión de credenciales de cliente. Una autorización correcta con el secreto del cliente devuelve un token de acceso.
-
Usuarios que han iniciado sesión anteriormente y han recibido tokens de actualización. La autenticación con un token de actualización devuelve un nuevo identificador y un nuevo token de acceso.
nota
Los usuarios que inicien sesión con un código de autorización otorgado en la interfaz de usuario alojada o mediante la federación siempre pueden actualizar sus tokens desde el punto de enlace del token. Los usuarios que inician sesión con las API operaciones
InitiateAuth
yAdminInitiateAuth
pueden actualizar sus tokens con el punto final del token cuando los dispositivos recordados no estén activos en su grupo de usuarios. Si los dispositivos recordados están activos, actualiza los tokens conAuthFlow
REFRESH_TOKEN_AUTH
las entradasInitiateAuth
oAdminInitiateAuth
API las solicitudes.
El punto de conexión del token pasa a estar disponible públicamente cuando agrega un dominio a su grupo de usuarios. Acepta HTTP POST solicitudes. Para garantizar la seguridad de la aplicación, PKCE utilícela los eventos de inicio de sesión con su código de autorización. PKCEverifica que el usuario que pasa el código de autorización es el mismo usuario que se autenticó. Para obtener más información al respectoPKCE, consulte IETF RFC 7636.
Puede obtener más información sobre los clientes de la aplicación del grupo de usuarios y sus tipos de concesiones, secretos de cliente, ámbitos autorizados y clientes IDs en. Configuración específica de la aplicación con clientes de aplicaciones Puedes obtener más información sobre la autorización M2M, la concesión de credenciales de clientes y la autorización con alcances de token de acceso en. Ámbitos, M2M y APIs con servidores de recursos
Para recuperar información sobre un usuario desde su token de acceso, pásala a tu userInfo punto final o a un GetUserAPIsolicitud.
POST /oauth2/token
El punto de enlace /oauth2/token
solo admite HTTPS POST
. El cliente de grupo de usuarios realiza solicitudes a este punto de enlace directamente y no mediante un navegador.
El punto de conexión de token admite la autenticación client_secret_basic
y client_secret_post
. Para obtener más información sobre la especificación OpenID Connect, consulte Autenticación de cliente
Parámetros de la solicitud en el encabezado
Authorization
-
Si al cliente se le ha emitido un secreto, el cliente puede pasar su entrada
client_id
client_secret
en el encabezado de autorización comoclient_secret_basic
HTTP autorización. También puede incluir elclient_id
yclient_secret
en el cuerpo de la solicitud como autorizaciónclient_secret_post
.La cadena de encabezado de autorización es Basic
Base64Encode(client_id:client_secret)
. El siguiente ejemplo es un encabezado de autorización para un cliente de aplicacionesdjc98u3jiedmi283eu928
con un secreto de clienteabcdef01234567890
, que utiliza la versión de la cadena codificada en Base64:djc98u3jiedmi283eu928:abcdef01234567890
Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
Content-Type
-
Establezca el valor del parámetro en
'application/x-www-form-urlencoded'
.
Parámetros de la solicitud en el cuerpo
grant_type
-
(Obligatorio) El tipo de OIDC concesión que quieres solicitar.
Debe ser
authorization_code
,refresh_token
oclient_credentials
. Puedes solicitar un token de acceso para un ámbito personalizado desde el punto final del token en las siguientes condiciones:-
Has activado el ámbito solicitado en la configuración del cliente de tu aplicación.
-
Has configurado el cliente de la aplicación con un secreto de cliente.
-
Usted habilita la concesión de credenciales de cliente en el cliente de su aplicación.
-
client_id
-
(Opcional) El ID de un cliente de aplicaciones de tu grupo de usuarios. Especifique el mismo cliente de aplicación que autenticó al usuario.
Debe proporcionar este parámetro si el cliente es público y no tiene un secreto o no tiene
client_secret_post
autorización.client_secret
client_secret
-
(Opcional) El secreto del cliente de la aplicación que autenticó al usuario. Obligatorio si el cliente de aplicación tiene un secreto de cliente y no ha enviado un encabezado
Authorization
. scope
-
(Opcional) Puede ser una combinación de cualquier ámbito personalizado asociado a un cliente de aplicación. Cualquier ámbito que solicite debe estar activado para el cliente de la aplicación. Si no, Amazon Cognito lo ignorará. Si el cliente no solicita ningún ámbito, el servidor de autenticación asigna todos los ámbitos personalizados que usted autorizó en la configuración del cliente de la aplicación.
Solo se usa si
grant_type
esclient_credentials
. redirect_uri
-
(Opcional) Debe ser el mismo
redirect_uri
que se usó para entrar.authorization_code
/oauth2/authorize
Debe proporcionar este parámetro, si lo
grant_type
estáauthorization_code
. refresh_token
-
(Opcional) Para generar nuevos tokens de acceso e ID para la sesión de un usuario, establece el valor de un
refresh_token
parámetro de tu/oauth2/token
solicitud en un token de actualización emitido anteriormente desde el mismo cliente de la aplicación. code
-
(Opcional) El código de autorización de una concesión de código de autorización. Debe proporcionar este parámetro si su solicitud de autorización incluía uno
grant_type
deauthorization_code
. code_verifier
-
(Opcional) El valor arbitrario con el que se calculó
code_challenge
una solicitud de concesión de código de autorizaciónPKCE.
Ejemplo de solicitudes con respuestas positivas
Intercambio de un código de autorización para los tokens
Ejemplo: POST solicitud
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token& Content-Type='application/x-www-form-urlencoded'& Authorization=Basic
ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
grant_type=authorization_code& client_id=1example23456789
& code=AUTHORIZATION_CODE
& redirect_uri=com.myclientapp://myclient/redirect
Ejemplo: respuesta
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
nota
El punto de enlace del token devuelve refresh_token
solo cuando grant_type
es authorization_code
.
Intercambio de credenciales de cliente para un token de acceso: secreto del cliente en un encabezado de autorización
Ejemplo: POST solicitud
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=Basic
ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
grant_type=client_credentials& client_id=1example23456789
& scope=resourceServerIdentifier1
/scope1
resourceServerIdentifier2
/scope2
Ejemplo: respuesta
HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "token_type": "Bearer", "expires_in": 3600 }
Intercambio de credenciales de cliente para un token de acceso: secreto del cliente en un cuerpo de solicitud
Ejemplo: POST solicitud
POST /oauth2/token HTTP/1.1 Content-Type: application/x-www-form-urlencoded X-Amz-Target: AWSCognitoIdentityProviderService.Client credentials request User-Agent: USER_AGENT Accept: / Accept-Encoding: gzip, deflate, br Content-Length: 177 Referer: http://auth.example.com/oauth2/token Host: auth.example.com Connection: keep-alive grant_type=client_credentials&client_id=
1example23456789
&scope=my_resource_server_identifier
%2Fmy_custom_scope
&client_secret=9example87654321
Ejemplo: respuesta
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Date: Tue, 05 Dec 2023 16:11:11 GMT x-amz-cognito-request-id: 829f4fe2-a1ee-476e-b834-5cd85c03373b { "access_token": "eyJra12345EXAMPLE", "expires_in": 3600, "token_type": "Bearer" }
Intercambiar un código de autorización otorgado PKCE por fichas
Ejemplo: solicitud POST
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token Content-Type='application/x-www-form-urlencoded'& Authorization=Basic
ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
grant_type=authorization_code& client_id=1example23456789
& code=AUTHORIZATION_CODE
& code_verifier=CODE_VERIFIER
& redirect_uri=com.myclientapp://myclient/redirect
Ejemplo: respuesta
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
nota
El punto de enlace del token devuelve refresh_token
solo cuando grant_type
es authorization_code
.
Intercambio de un token de actualización para los tokens
Ejemplo: POST solicitud
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=Basic
ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
grant_type=refresh_token& client_id=1example23456789
& refresh_token=eyJj3example
Ejemplo: respuesta
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"token_type": "Bearer",
"expires_in": 3600
}
nota
El punto de enlace del token devuelve refresh_token
solo cuando grant_type
es authorization_code
.
Ejemplos de respuestas negativas
Ejemplo: respuesta de error
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
{
"error":"invalid_request|invalid_client|invalid_grant|unauthorized_client|unsupported_grant_type"
}
invalid_request
-
Falta un parámetro necesario en la solicitud, la solicitud incluye un valor de parámetro no admitido (distinto de
unsupported_grant_type
) o la solicitud tiene un formato incorrecto. Por ejemplo,grant_type
esrefresh_token
perorefresh_token
no está incluido. invalid_client
-
Error de autenticación del cliente. Por ejemplo, cuando el cliente incluye
client_id
yclient_secret
en el encabezado de la autorización, pero no existe un cliente con esosclient_id
yclient_secret
. invalid_grant
-
El token de actualización se ha revocado.
El código de autorización ya se ha utilizado o no existe.
El cliente de la aplicación no tiene acceso de lectura a todos los atributos en el ámbito solicitado. Por ejemplo, su aplicación solicita el ámbito
email
y su cliente de aplicación puede leer el atributoemail
, pero noemail_verified
. unauthorized_client
-
El cliente no tiene permiso para el flujo de concesión de códigos o para la actualización de tokens.
unsupported_grant_type
-
Se devuelve si
grant_type
es distinto deauthorization_code
,refresh_token
oclient_credentials
.