Claims

Os claims são processados primeiro no método de autenticação e depois no registo de aplicação, onde é possível decidir quais os claims que passam para o passo seguinte e executar transformações e tarefas de claims.

Todas as comparações de claims são sensíveis a maiúsculas e minúsculas.

O processo de claims começa no método de autenticação quando um utilizador se autentica. Aí é possível executar transformações e tarefas de claims e configurar quais os claims que têm de ser encaminhados para o passo seguinte. Depois, o processo de claims continua no registo de aplicação, onde também é possível fazer transformações de claims e configurar quais os claims que têm de ser emitidos para a aplicação / API.

Num cenário de Client Credentials Grant, o processo de claims é executado apenas no registo de aplicação. O mesmo acontece com as transformações de claims e com a configuração de quais os claims que têm de ser emitidos para a aplicação / API.

Método de autenticação

Tanto num método de autenticação OpenID Connect como SAML 2.0, os claims são encaminhados ao adicioná-los à lista Forward claims. Todos os claims são encaminhados se um wildcard * for adicionado à lista Forward claims.

Um método de autenticação emite dois claims que podem ser lidos no registo de aplicação e usados em transformações e tarefas de claims. Os claims aplicam-se sempre ao último método de autenticação.
Os claims emitidos pelo método de autenticação (encaminhamento predefinido):

  • auth_method contém o nome do método de autenticação; o nome é único num ambiente.
  • auth_method_type contém o tipo de método de autenticação: login, oidc, oauth2, saml2 ou env_link.

Um claim sub e os tokens recebidos de um Identity Provider externo ficam aninhados com um símbolo pipe (|) após o nome do método de autenticação. Exemplos:

  • Um sub externo com o valor afeda2a3-c08b-4bbb-ab77-35138dd2ef2d passa a ter o valor aninhado the-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d
  • Um access token externo com o valor eyJhG.cRwczov...nNjb3B.lIjoi é adicionado no claim access_token com o valor aninhado the-auth-method|eyJhG.cRwczov...nNjb3B.lIjoi
  • Se o OpenID Provider externo devolver um refresh token, este pode ser encaminhado no claim refresh_token com o valor aninhado the-auth-method|refresh-token-value

Registo de aplicação

Tanto num registo de aplicação OpenID Connect, OAuth 2.0 como SAML 2.0, os claims são emitidos para a aplicação / API ao adicioná-los à lista Issue claims. Todos os claims são emitidos para a aplicação / API se um wildcard * for adicionado à lista Issue claims.

Um registo de aplicação OpenID Connect pode diferenciar se um claim é emitido apenas no access token ou também no ID token.

Um registo de aplicação OpenID Connect e OAuth 2.0 também pode encaminhar claims através de um scope. Isto é feito adicionando o claim ou claims à lista Voluntary claims de um scope. Os claims são depois emitidos se a aplicação cliente pedir esse scope.
Um registo de aplicação OpenID Connect também pode diferenciar, nos voluntary scope claims, se um claim é emitido apenas no access token ou também no ID token.

A sua privacidade

A sua privacidade

Usamos cookies para melhorar a sua experiência nos nossos sites. Clique no botão 'Aceitar todos os cookies' para concordar com a utilização de cookies. Para recusar cookies não essenciais, clique em 'Apenas cookies necessários'.

Visite a nossa página de Política de Privacidade para saber mais