O endpoint do emissor de tokens
O endpoint de token/oauth2/token emite tokens web JSON (JWTs) para aplicações que desejam concluir fluxos de concessão de código de autorização e credenciais de cliente. Esses tokens são o resultado da autenticação com um grupo de usuários. Eles contêm informações sobre o usuário (token de ID), o nível de acesso do usuário (token de acesso) e o direito do usuário de persistir na sessão conectada (token de atualização). As bibliotecas independentes do OpenID Connect (OIDC) gerenciam cargas úteis de solicitações e respostas desse endpoint. Os tokens fornecem prova verificável de autenticação, informações de perfil e um mecanismo para acesso a sistemas de backend.
O servidor de autorização do OAuth 2.0 do grupo de usuários emite JSON web tokens (JWTs) do endpoint do token para os tipos de sessão a seguir:
-
Usuários que concluíram uma solicitação de concessão de código de autorização. O resgate bem-sucedido de um código retorna tokens de ID, acesso e atualização.
-
Sessões entre máquinas (M2M) que concluíram uma concessão de credenciais de cliente. A autorização bem-sucedida com o segredo do cliente retorna um token de acesso.
-
Usuários que já fizeram login e receberam tokens de atualização. A autenticação de token de atualização retorna novos tokens de ID e acesso.
nota
Os usuários que fazem login com uma concessão de código de autorização no login gerenciado ou por meio da federação sempre podem atualizar seus tokens por meio do endpoint de token. Usuários que fazem login com as operações da API
InitiateAutheAdminInitiateAuthpodem atualizar seus tokens com o endpoint do token quando os dispositivos memorizados não estão ativos em seu grupo de usuários. Se os dispositivos memorizados estiverem ativos, atualize os tokens com a API relevante ou a operação de atualização de token do SDK para seu cliente de aplicação.
O endpoint do token fica disponível ao público quando você adiciona um domínio ao grupo de usuários. Ele aceita solicitações HTTP POST. Para fins de segurança da aplicação, use o PKCE com eventos de login com código de autorização. O PKCE verifica se o usuário que está transmitindo um código de autorização é o mesmo usuário que se autenticou. Para obter mais informações sobre PKCE, consulte IETF RFC 7636
Você pode aprender mais sobre os clientes da aplicação do grupo de usuários e seus tipos de concessão, segredos do cliente, escopos permitidos e IDs de clientes em Configurações específicas da aplicação com clientes de aplicação. Você pode aprender mais sobre autorização M2M, concessões de credenciais de clientes e autorização com escopos de token de acesso em Escopos, M2M e APIs com servidores de recursos.
Para recuperar informações sobre um usuário por meio do token de acesso, transmita-o para endpoint userinfo ou para uma solicitação de API GetUser. O token de acesso deve conter os escopos apropriados para essas solicitações.
Formatar uma solicitação POST para o endpoint de token
O endpoint /oauth2/token só é compatível com HTTPS POST. Esse endpoint não é interativo com o usuário. Gerencie solicitações de token com uma biblioteca OpenID Connect (OIDC)
O endpoint de token é compatível com a autenticação de client_secret_basic e client_secret_post. Para obter mais informações sobre a especificação do OIDC, consulte Client Authentication
Parâmetros de solicitação no cabeçalho
Você pode transmitir os parâmetros a seguir no cabeçalho da sua solicitação para o endpoint de token.
Authorization-
Se um segredo foi emitido para o cliente, ele precisa passar o
client_ide oclient_secretno cabeçalho de autorização como autorização HTTPclient_secret_basic. Você também pode incluir oclient_ideclient_secretno corpo da solicitação como autorização declient_secret_post.A string do cabeçalho de autorização é Basic
Base64Encode(client_id:client_secret). O exemplo a seguir é um cabeçalho de autorização para o cliente da aplicaçãodjc98u3jiedmi283eu928com segredo do clienteabcdef01234567890usando a versão codificada em Base64 da stringdjc98u3jiedmi283eu928:abcdef01234567890:Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw Content-Type-
Defina o valor desse parâmetro como
'application/x-www-form-urlencoded'.
Parâmetros de solicitação no corpo
A seguir estão os parâmetros que você pode solicitar em formato x-www-form-urlencoded no corpo da solicitação para o endpoint de token.
grant_type-
Obrigatória.
O tipo de concessão do OIDC que você deseja solicitar.
Deve ser
authorization_codeourefresh_tokenouclient_credentials. Você pode solicitar um token de acesso para um escopo personalizado a partir do endpoint do token sob as seguintes condições:-
Você habilitou o escopo solicitado na configuração do cliente da aplicação.
-
Você configurou o cliente da aplicação com um segredo do cliente.
-
Você ativa a concessão de credenciais do cliente em seu cliente de aplicação.
nota
O endpoint de token retorna um token de atualização somente quando o
grant_typeéauthorization_code. -
client_id-
Opcional. Não é obrigatório quando você fornece o ID do cliente de aplicação no cabeçalho
Authorization.O ID de um cliente de aplicação no grupo de usuários. Especifique o mesmo cliente de aplicação que autenticou o usuário.
Você deve fornecer esse parâmetro se o cliente for público e não tiver um segredo ou com
client_secretna autorizaçãoclient_secret_post. client_secret-
Opcional. Não é obrigatório quando você fornece o segredo do cliente no cabeçalho
Authorizatione quando o cliente de aplicação não tem um segredo.O segredo do cliente de aplicação, caso o cliente de aplicação tenha um, para autorização
client_secret_post. scope-
Opcional.
Pode ser uma combinação de quaisquer escopos associados ao seu cliente de aplicação. O Amazon Cognito ignora escopos na solicitação que não são permitidos para o cliente de aplicação solicitado. Se você não fornecer esse parâmetro de solicitação, o servidor de autorização retornará uma declaração
scopede token de acesso com todos os escopos de autorização que você habilitou na configuração do cliente de aplicação. É possível solicitar qualquer um dos escopos permitidos para o cliente de aplicação solicitado: escopos padrão, escopos personalizados de servidores de recursos e o escopo de autoatendimento do usuárioaws.cognito.signin.user.admin. redirect_uri-
Opcional. Não é obrigatório para concessões de credenciais de clientes.
Precisa ser o mesmo
redirect_uriusado para obter oauthorization_codeem/oauth2/authorize.Você deve fornecer esse parâmetro se
grant_typeforauthorization_code. refresh_token-
Opcional. Usado somente quando o usuário já tem um token de atualização e deseja obter um novo ID e tokens de acesso.
Para gerar novos tokens de acesso e ID para a sessão de um usuário, defina o valor de
refresh_tokenpara um token de atualização válido emitido pelo cliente de aplicação solicitado.Retorna um novo token de atualização com um novo token de ID e acesso quando a alternância de tokens de atualização está ativa, caso contrário, retorna somente tokens de ID e acesso. Se o token de acesso original estiver vinculado a um recurso da API, o novo token de acesso manterá o URL da API solicitado na declaração
aud. code-
Opcional. Obrigatório somente em concessões de código de autorização.
O código de autorização de uma concessão de código de autorização. Você deve fornecer esse parâmetro se sua solicitação de autorização incluir
grant_typedeauthorization_code. aws_client_metadata-
Opcional.
Informações que você deseja transmitir para Acionador do Lambda antes da geração do token em fluxos de autorização máquina-a-máquina (M2M). Sua aplicação pode coletar informações de contexto sobre a sessão e transmiti-las neste parâmetro. Quando você transmite
aws_client_metadatano formato JSON codificado por URL, o Amazon Cognito o inclui no evento de entrada para sua função do Lambda do acionador. Sua versão do evento de acionador de pré-geração de tokens ou a versão global de acionador do Lambda deve ser configurada para a versão três ou posterior. Embora o Amazon Cognito aceite solicitações para este endpoint em fluxos M2M de código de autorização e credenciais do cliente, seu grupo de usuários só transmiteaws_client_metadatapara o acionador de pré-geração de tokens por meio de solicitações de credenciais do cliente. code_verifier-
Opcional. Obrigatório somente se você tiver fornecido os parâmetros
code_challenge_methodecode_challengeem sua solicitação de autorização inicial.O verificador de código gerado que sua aplicação usou para calcular
code_challengeem uma solicitação de concessão de código de autorização com PKCE.
Como trocar um código de autorização por tokens
A solicitação a seguir gera tokens de ID, acesso e atualização com sucesso após a autenticação com uma concessão de código de autorização. A solicitação transmite o segredo do cliente no formato client_secret_basic no cabeçalho Authorization.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token& Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=authorization_code& client_id=1example23456789& code=AUTHORIZATION_CODE& redirect_uri=com.myclientapp://myclient/redirect
A resposta emite novos tokens de ID, acesso e atualização para o usuário, com metadados adicionais.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
Credenciais do cliente com autorização básica
A solicitação a seguir de uma aplicação M2M solicita a concessão de credenciais do cliente. Como as credenciais do cliente exigem um segredo do cliente, a solicitação é autorizada com um cabeçalho Authorization derivado do ID e do segredo do cliente de aplicação. A solicitação resulta em um token de acesso com os dois escopos solicitados. A solicitação também inclui metadados do cliente que fornecem informações de endereço IP e um token emitido para o usuário atribuído a essa concessão. O Amazon Cognito transmite os metadados do cliente para o acionador do Lambda de pré-geração de tokens.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=client_credentials& client_id=1example23456789& scope=resourceServerIdentifier1%2Fscope1%20resourceServerIdentifier2%2Fscope2& &aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D
O Amazon Cognito transmite o evento de entrada a seguir para o acionador do Lambda de pré-geração de tokens.
{ version: '3', triggerSource: 'TokenGeneration_ClientCredentials', region: 'us-east-1', userPoolId: 'us-east-1_EXAMPLE', userName: 'ClientCredentials', callerContext: { awsSdkVersion: 'aws-sdk-unknown-unknown', clientId: '1example23456789' }, request: { userAttributes: {}, groupConfiguration: null, scopes: [ 'resourceServerIdentifier1/scope1', 'resourceServerIdentifier2/scope2' ], clientMetadata: { 'onBehalfOfToken': 'eyJra789ghiEXAMPLE', 'ClientIpAddress': '192.0.2.252' } }, response: { claimsAndScopeOverrideDetails: null } }
A resposta retorna um token de acesso. As concessões de credenciais do cliente são para autorização máquina-a-máquina (M2M) e retornam somente tokens de acesso.
HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "token_type": "Bearer", "expires_in":3600}
Credenciais do cliente com autorização do corpo POST
A solicitação de concessão de credenciais do cliente a seguir inclui o parâmetro client_secret no corpo da solicitação e não inclui um cabeçalho Authorization. Essa solicitação usa a sintaxe de autorização client_secret_post. A solicitação resulta em um token de acesso com o escopo solicitado. A solicitação também inclui metadados do cliente que fornecem informações de endereço IP e um token emitido para o usuário atribuído a essa concessão. O Amazon Cognito transmite os metadados do cliente para o acionador do Lambda de pré-geração de tokens.
POST /oauth2/token HTTP/1.1 Content-Type: application/x-www-form-urlencoded X-Amz-Target: AWSCognitoIdentityProviderService.Client credentials request User-Agent:USER_AGENTAccept: / Accept-Encoding: gzip, deflate, br Content-Length: 177 Referer: http://auth.example.com/oauth2/token Host:auth.example.comConnection: keep-alive grant_type=client_credentials& client_id=1example23456789& scope=my_resource_server_identifier%2Fmy_custom_scope&client_secret=9example87654321& aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D
O Amazon Cognito transmite o evento de entrada a seguir para o acionador do Lambda de pré-geração de tokens.
{ version: '3', triggerSource: 'TokenGeneration_ClientCredentials', region: 'us-east-1', userPoolId: 'us-east-1_EXAMPLE', userName: 'ClientCredentials', callerContext: { awsSdkVersion: 'aws-sdk-unknown-unknown', clientId: '1example23456789' }, request: { userAttributes: {}, groupConfiguration: null, scopes: [ 'resourceServerIdentifier1/my_custom_scope' ], clientMetadata: { 'onBehalfOfToken': 'eyJra789ghiEXAMPLE', 'ClientIpAddress': '192.0.2.252' } }, response: { claimsAndScopeOverrideDetails: null } }
A resposta retorna um token de acesso. As concessões de credenciais do cliente são para autorização máquina-a-máquina (M2M) e retornam somente tokens de acesso.
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" }
Concessão de código de autorização com PKCE
O exemplo a seguir conclui uma solicitação de autorização que incluiu os parâmetros code_challenge_method e code_challenge em uma solicitação de concessão de código de autorização com PKCE.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=authorization_code& client_id=1example23456789& code=AUTHORIZATION_CODE& code_verifier=CODE_VERIFIER& redirect_uri=com.myclientapp://myclient/redirect
A resposta retorna tokens de ID, acesso e atualização da verificação bem-sucedida do PKCE pela aplicação.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
Atualização de token sem alternância de tokens de atualização
O exemplo de solicitações a seguir fornece um token de atualização para um cliente de aplicação no qual a alternância de tokens de atualização está inativa. Como o cliente de aplicação tem um segredo do cliente, a solicitação fornece um cabeçalho Authorization.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=refresh_token& client_id=1example23456789& refresh_token=eyJj3example
A resposta retorna novos tokens de ID e acesso.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"token_type": "Bearer",
"expires_in": 3600
}
Atualização de token com alternância de tokens de atualização
O exemplo de solicitações a seguir fornece um token de atualização para um cliente de aplicação no qual a alternância de tokens de atualização está ativa. Como o cliente de aplicação tem um segredo do cliente, a solicitação fornece um cabeçalho Authorization.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=refresh_token& client_id=1example23456789& refresh_token=eyJj3example
A resposta retorna novos tokens de ID, acesso e atualização.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj4example",
"token_type": "Bearer",
"expires_in": 3600
}
Exemplos de respostas negativas
Solicitações malformadas geram erros no endpoint de token. Veja a seguir um mapa geral do corpo da resposta quando as solicitações de token geram um erro.
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-
A solicitação não tem um parâmetro obrigatório, inclui um valor de parâmetro não compatível (diferente de
unsupported_grant_type) ou está malformado. Por exemplo,grant_typeérefresh_token, masrefresh_tokennão está incluído. invalid_client-
Falha na autenticação do cliente. Por exemplo, quando o cliente inclui
client_ideclient_secretno cabeçalho de autorização, mas não há tal cliente com esseclient_ideclient_secret. invalid_grant-
O token de atualização foi revogado.
O código de autorização já foi consumido ou não existe.
O cliente da aplicação não tem acesso de leitura a todos os atributos no escopo solicitado. Por exemplo, a aplicação solicita o escopo
emaile o cliente da aplicação consegue ler o atributoemail, mas nãoemail_verified. unauthorized_client-
O cliente não tem permissão para fluxo de concessão de código ou para tokens de atualização.
unsupported_grant_type-
Retornado se
grant_typefor diferente deauthorization_code,refresh_tokenouclient_credentials.