O endpoint do emissor de tokens - Amazon Cognito

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

O endpoint do emissor de tokens

O endpoint do token OAuth 2.0 /oauth2/token emite tokens web JSON ()JWTs. 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.

Seu servidor de autorização do grupo de usuários OAuth 2.0 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. Machine-to-machine Sessões (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 no login gerenciado 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 memorizados não estão ativos em seu grupo de usuários. Se os dispositivos memorizados estiverem ativos, atualize os tokens com AuthFlow de REFRESH_TOKEN_AUTH nas solicitações de API InitiateAuth ou AdminInitiateAuth.

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 do aplicativo do grupo de usuários e seus tipos de concessão, segredos do cliente, escopos autorizados e clientes IDs emConfiguraçõ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 a partir de seu token de acesso, passe-as para o seu endpoint userinfo ou para um GetUserSolicitação de API.

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 de 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 da aplicação djc98u3jiedmi283eu928 com segredo do cliente abcdef01234567890 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 concessão 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ê 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.

client_id

(Opcional) 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_secret na autorização client_secret_post.

client_secret

(Opcional) O segredo para o cliente de aplicação que autenticou o 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 quaisquer escopos personalizados associados a um cliente de aplicação. Qualquer escopo que você solicitar deve ser ativado para o cliente de aplicação. Caso contrário, o Amazon Cognito o ignorará. Se o cliente não solicita nenhum escopo, o servidor de autenticação atribui todos os escopos personalizados que você autorizou na configuração do cliente da aplicação.

Usado somente se o grant_type for client_credentials.

redirect_uri

(Opcional) Precisa ser o mesmo redirect_uri usado para obter o authorization_code em /oauth2/authorize.

Você deve fornecer esse parâmetro se grant_type for authorization_code.

refresh_token

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

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 grant_type de authorization_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.