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 /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:
-
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.
-
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.
-
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
eAdminInitiateAuth
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 comAuthFlow
deREFRESH_TOKEN_AUTH
nas solicitações de APIInitiateAuth
ouAdminInitiateAuth
.
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
Parâmetros de solicitação no cabeçalho
Authorization
-
Se um segredo foi emitido para o cliente, ele precisa passar o
client_id
e oclient_secret
no cabeçalho de autorização como autorização HTTPclient_secret_basic
. Você também pode incluir oclient_id
eclient_secret
no 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çãodjc98u3jiedmi283eu928
com segredo do clienteabcdef01234567890
usando 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
grant_type
-
(Obrigatório) O tipo de concessão do OIDC que você deseja solicitar.
Deve ser
authorization_code
ourefresh_token
ouclient_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çãoclient_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
forclient_credentials
. redirect_uri
-
(Opcional) Precisa ser o mesmo
redirect_uri
usado para obter oauthorization_code
em/oauth2/authorize
.Você deve fornecer esse parâmetro se
grant_type
forauthorization_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
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
, masrefresh_token
não está incluído. invalid_client
-
Falha na autenticação do cliente. Por exemplo, quando o cliente inclui
client_id
eclient_secret
no cabeçalho de autorização, mas não há tal cliente com esseclient_id
eclient_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 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_type
for diferente deauthorization_code
,refresh_token
ouclient_credentials
.