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á.
Quando o OIDC emite tokens de ID que contêm atributos do usuário, o OAuth 2.0 implementa o endpoint. /oauth2/userInfo
Um usuário ou cliente autenticado recebe um token de acesso com uma reivindicação scopes
. Essa reivindicação determina os atributos que o servidor de autorização deve retornar. Quando uma aplicação apresenta um token de acesso ao endpoint userInfo
, o servidor de autorização retorna um corpo de resposta que contém os atributos do usuário que estão dentro dos limites definidos pelos escopos do token de acesso. Essa aplicação pode recuperar informações sobre um usuário a partir do endpoint userInfo
, desde que tenha um token de acesso válido com pelo menos uma reivindicação de escopo openid
.
O endpoint userInfo
é um endpoint userInfoopenid
deve ser uma das reivindicações do token de acesso.
O Amazon Cognito emite tokens de acesso em resposta a solicitações de API de grupos de usuários, como InitiateAuth. Como eles não contêm nenhum escopo, o userInfo O endpoint não aceita esses tokens de acesso. Em vez disso, você deve apresentar os tokens de acesso do endpoint de token.
Seu provedor de identidade terceirizado (IdP) OAuth 2.0 também hospeda um userInfo ponto final. Quando o usuário faz a autenticação com esse IdP, o Amazon Cognito troca silenciosamente um código de autorização com o endpoint token
do IdP. Seu grupo de usuários passa o token de acesso do IdP para autorizar a recuperação das informações do usuário do endpoint userInfo
do IdP.
Os escopos no token de acesso de um usuário são determinados pelo parâmetro de scopes
solicitação nas solicitações de autenticação ou pelos escopos que o gatilho Lambda antes da geração do token adiciona. Você pode decodificar tokens de acesso e examinar as scope
declarações para ver os escopos de controle de acesso que elas contêm. A seguir estão algumas combinações de escopo que influenciam os dados retornados do userInfo
endpoint. O escopo reservado do Amazon Cognito não aws.cognito.signin.user.admin
tem efeito sobre os dados retornados desse endpoint.
Exemplos de escopos no token de acesso e seus efeitos na resposta userInfo
openid
-
Retorna uma resposta com todos os atributos do usuário que o cliente do aplicativo pode ler.
openid profile
-
Retorna os atributos do usuário
name
family_name
given_name
middle_name
,nickname
preferred_username
,profile
,picture
,website
,gender
,birthdate
,zoneinfo
,locale
,,updated_at
e. Também retorna atributos personalizados. Em clientes de aplicativos que não têm acesso de leitura a cada atributo, a resposta a esse escopo são todos os atributos dentro da especificação à qual seu cliente de aplicativo tem acesso de leitura. openid email
-
Retorna informações básicas do perfil
email
eemail_verified
os atributos e. openid phone
-
Retorna informações básicas do perfil
phone_number
ephone_number_verified
os atributos e.
GET /oauth2/userInfo
Seu aplicativo gera solicitações diretamente para esse endpoint, não por meio de um navegador.
Para obter mais informações, consulte .UserInfo Endpoint
Tópicos
Parâmetros de solicitação no cabeçalho
Authorization: Bearer
<access_token>
-
Repasse o token de acesso no campo do cabeçalho da autorização.
Obrigatório.
Exemplo - solicitação
GET /oauth2/userInfo HTTP/1.1 Content-Type: application/x-amz-json-1.1 Authorization: Bearer eyJra12345EXAMPLE User-Agent:
[User agent]
Accept: */* Host: auth.example.com Accept-Encoding: gzip, deflate, br Connection: keep-alive
Exemplo - resposta positiva
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Content-Length:
[Integer]
Date:[Timestamp]
x-amz-cognito-request-id:[UUID]
X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 Strict-Transport-Security: max-age=31536000 ; includeSubDomains X-Frame-Options: DENY Server: Server Connection: keep-alive { "sub": "[UUID]
", "email_verified": "true", "custom:mycustom1": "CustomValue", "phone_number_verified": "true", "phone_number": "+12065551212", "email": "bob@example.com", "username": "bob" }
Para obter uma lista de solicitações OIDC, consulte Solicitações padrãoemail_verified
e phone_number_verified
como strings.
Exemplo - respostas negativas
Exemplo - solicitação inválida
HTTP/1.1 400 Bad Request
WWW-Authenticate: error="invalid_request",
error_description="Bad OAuth2 request at UserInfo Endpoint"
invalid_request
-
A solicitação não possui um parâmetro obrigatório, inclui um valor de parâmetro não compatível ou contém informações incorretas.
Exemplo - token inválido
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="Access token is expired, disabled, or deleted, or the user has globally signed out."
invalid_token
-
O token de acesso está expirado, revogado, informado incorretamente ou inválido.