Endpoint de token - Amazon Cognito
POST /oauth2/token

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Endpoint de token

O endpoint do token do OAuth 2.0 em /oauth2/token emite tokens JSON da web (JWTs).

Seu servidor de autorização OAuth 2.0 do grupo de usuários emite tokens web JSON (JWTs) do endpoint do token para os seguintes tipos de sessões:

  1. 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.

  2. Sessões M achine-to-machine (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.

  3. 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 na interface hospedada ou por meio da federação sempre podem atualizar seus tokens a partir do endpoint do token. Usuários que fazem login com as operações da API InitiateAuth e AdminInitiateAuth podem atualizar seus tokens com o endpoint do token quando os dispositivos lembrados não estão ativos em seu grupo de usuários. Se os dispositivos lembrados estiverem ativos, atualize os tokens com as solicitações AuthFlow REFRESH_TOKEN_AUTH de entrada InitiateAuth ou de AdminInitiateAuth API.

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 segurança do aplicativo, use o PKCE com seus 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 o 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 de clientes, escopos autorizados e IDs de clientes em Clientes de aplicações de grupos de usuários. 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 autorização de API com servidores de recursos

Para recuperar informações sobre um usuário a partir do token de acesso, passe-as para você Endpoint do UserInfo ou para uma solicitação de GetUserAPI.

POST /oauth2/token

O endpoint /oauth2/token só é compatível com HTTPS POST. Sua aplicação faz solicitações para esse endpoint diretamente, e não por meio do navegador do usuário.

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 OpenID Connect, consulte Autenticação do cliente. Para obter mais informações sobre o endpoint de token na especificação do OpenID Connect, consulte Endpoint de token.

Parâmetros de solicitação no cabeçalho

Authorization

Se um segredo foi emitido para o cliente, ele precisa passar o client_id e o client_secret no cabeçalho de autorização como autorização HTTP client_secret_basic. Você também pode incluir o client_id e client_secret no corpo da solicitação como autorização de client_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 do aplicativo djc98u3jiedmi283eu928 com segredo do clienteabcdef01234567890, usando a versão codificada em Base64 da string: djc98u3jiedmi283eu928: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

grant_type

(Obrigatório) O tipo de subsídio do OIDC que você deseja solicitar.

Deve ser authorization_code ou refresh_token ou client_credentials. Você pode solicitar um token de acesso para um escopo personalizado a partir do endpoint do token sob as seguintes condições:

  • Você ativou o escopo solicitado na configuração do seu cliente de aplicativo.

  • Você configurou seu cliente de aplicativo com um segredo de cliente.

  • Você ativa a concessão de credenciais de cliente em seu cliente de aplicativo.

client_id

(Opcional) O ID de um cliente de aplicativo em seu grupo de usuários. Especifique o mesmo cliente de aplicativo que autenticou seu usuário.

Você deve fornecer esse parâmetro se o cliente for público e não tiver um segredo ou se não tiver client_secret_post autorização. client_secret

client_secret

(Opcional) O segredo do cliente do aplicativo que autenticou seu usuário. Obrigatório se o cliente de aplicação tiver um segredo de cliente e você não tiver enviado uma cabeçalho de Authorization.

scope

(Opcional) Pode ser uma combinação de qualquer escopo personalizado associado a um cliente de aplicativo. Qualquer escopo que você solicitar deve ser ativado para o cliente do aplicativo. Caso contrário, o Amazon Cognito o ignorará. Se o cliente não solicitar nenhum escopo, o servidor de autenticação atribuirá todos os escopos personalizados que você autorizou na configuração do seu cliente de aplicativo.

Usado somente se o grant_type for client_credentials.

redirect_uri

(Opcional) Deve ser o mesmo redirect_uri que foi usado para authorization_code entrar/oauth2/authorize.

Você deve fornecer esse parâmetro se grant_type estiverauthorization_code.

refresh_token

(Opcional) Para gerar novos tokens de acesso e ID para a sessão de um usuário, defina o valor de um refresh_token parâmetro em sua /oauth2/token solicitação como um token de atualização emitido anteriormente pelo mesmo cliente do aplicativo.

code

(Opcional) 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 um grant_type deauthorization_code.

code_verifier

(Opcional) O valor arbitrário que você usou para calcular o code_challenge em uma solicitação de concessão de código de autorização com o PKCE.

Exemplos de solicitações com respostas positivas

Como trocar um código de autorização por tokens

Exemplo — solicitação 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&
                            redirect_uri=com.myclientapp://myclient/redirect

Exemplo — resposta

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

O endpoint de token retorna refresh_token somente quando o grant_type é authorization_code.

Trocar credenciais de cliente para um token de acesso: segredo de cliente no cabeçalho de autorização

Exemplo — solicitação POST

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

Exemplo — resposta

HTTP/1.1 200 OK
                            Content-Type: application/json
                            
                            {
                            "access_token":"eyJra1example", 
                            "token_type":"Bearer", 
                            "expires_in":3600
                            }

Trocar credenciais de cliente para um token de acesso: segredo de cliente no corpo da solicitação

Exemplo — solicitação POST

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

Exemplo — resposta

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"
}

Como trocar uma concessão de código de autorização com PKCE por tokens

Exemplo — solicitação 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

Exemplo — resposta

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

O endpoint de token retorna refresh_token somente quando o grant_type é authorization_code.

Como trocar um token de atualização por tokens

Exemplo — solicitação POST

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

Exemplo — resposta

HTTP/1.1 200 OK
                           Content-Type: application/json
                           
                           {
                           "access_token":"eyJra1example", 
                           "id_token":"eyJra2example",
                           "token_type":"Bearer", 
                           "expires_in":3600
                                 }
nota

O endpoint de token retorna refresh_token somente quando o grant_type é authorization_code.

Exemplos de respostas negativas

Exemplo — resposta de 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 , mas refresh_token não está incluído.

invalid_client

Falha na autenticação do cliente. Por exemplo, quando o cliente inclui client_id e client_secret no cabeçalho de autorização, mas não há tal cliente com esse client_id e client_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 email e o cliente da aplicação consegue ler o atributo email, mas não email_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_type for diferente de authorization_code, refresh_token ou client_credentials.