Table of Contents

Solicitação de Autorização

Esta parte descreve os requisitos para o endpoint de autorização, focando principalmente nas diferenças entre rfc 6749 e OpenID Connect. Se você estiver familiarizado com as especificações, você pode pular este capítulo e pular para a implementação do endpoint de autorização.

1. Caminho

Quanto ao caminho do ponto final da autorização, apenas um requisito da RFC 6749 é que “O ponto final URI NÃO deve incluir um componente de fragmento”. (veja 3.1 Ponto final de autorização). Enquanto esse requisito estiver satisfeito, um serviço pode nomear seu ponto final de autorização livremente. Por exemplo /auth/authorization é um caminho válido de um ponto final de autorização. Um exemplo de um URI inteiro com o caminho é https://example.com/auth/authorization.

2. Segurança

A RFC 6749 exige que o ponto final da autorização use TLS (Transport Layer Security).

3. Métodos HTTP

De acordo com RFC 6749, 3.1. Endpoint de autorização, o ponto final da autorização deve suportar HTTP GET método, e HTTP POST o método é opcional. Contudo OpenID Connect Core 1.0, 3.1.2.1. Solicitação de autenticação exige que o suporte de endpoint de autorização HTTP POST método. No caso de POST, os parâmetros de solicitação devem ser formatados em application/x-www-form-urlencoded.

Table. HTTP Methods Of The Authorization Endpoint

HTTP method	RFC 6749	OpenID Connect
GET	MUST	MUST
POST	MAY	MUST

4. Parâmetros de solicitação

RFC 6749 define 4 tipos de subvenção (= fluxos para obter um token de acesso) em 1.3. Concessão de autorização. Entre os quatro, Concessão do Código de Autorização (também conhecido como Fluxo de Código de Autorização) e Subvenção Implícita (também conhecido como Fluxo Implícito) acesse o ponto final da autorização. Ambos os tipos de subvenção tomam os mesmos parâmetros de solicitação mostrados na tabela abaixo.

Table. Request Parameters For The Authorization Endpoint In RFC 6749

Name	Requisitos	Descrição
`response_type`	REQUERIDO	`code` para concessão de código de autorização e `token` para Grant Implícito.
`client_id`	REQUERIDO	O ID do cliente do aplicativo do cliente que está fazendo a solicitação de autorização. Um ID do cliente é um número ou string opaco emitido por um serviço.
`redirect_uri`	OPCIONAIS	A URL à qual o aplicativo cliente solicita o resultado da solicitação de autorização para ser relatada. Se o aplicativo do cliente tiver registrado URIs de redirecionamento múltiplo ou não tiver registrado qualquer URI redirecionado (isso é permitido quando o tipo de cliente do aplicativo cliente é “confidencial”), este parâmetro de solicitação é OBRIGATÓRIO.
`scope`	OPCIONAIS	Uma lista de escopos delimitados pelo espaço (= permissões) que o aplicativo do cliente requer. Os valores de escopo válidos são definidos por um serviço. Algumas implementações do OAuth 2.0 (por exemplo, Facebook) exigem uma lista delimitada por vírgula, mas é apenas uma violação contra a especificação.
`state`	RECOMENDADO	Um valor opaco que o aplicativo do cliente pode usar. Se esse parâmetro de solicitação estiver contido na solicitação de autorização, ele será passado para o redirecionamento URI.

Um dos maiores impactos introduzidos pelo OpenID Connect no OAuth 2.0 são as adições dos parâmetros de solicitação e os valores de parâmetros de solicitação ao ponto final da autorização. A maioria deles são descritos em OpenID Connect Core 1.0, 3.1.2.1. Solicitação de autenticação. A tabela a seguir é uma lista agregada de parâmetros de solicitação definidos em RFC 6749, OpenID Connect e outras especificações.

Table. Request Parameters For The Authorization Endpoint In OpenID Connect

Nome	Requerido	Descrição
`response_type`	REQUERIDO	Na RFC 6749, os valores válidos deste parâmetro de solicitação são apenas dois, ou seja, `code` e `token`. No entanto, o OpenID Connect estendeu-os a combinações de `code`, `id_token` e `token` ou `none`. Como resultado, os valores válidos são os seguintes. `none` `code` `token` `id_token` `code token` `code id_token` `id_token token` `code id_token token` Ver OAuth 2.0 Práticas de codificação do tipo de resposta múltipla para detalhes.
`client_id`	REQUERIDO	O mesmo requisito que rfc 6749.
`redirect_uri`	REQUERIDO	Na RFC 6749, este parâmetro de solicitação é OPCIONAL. Mas no OpenID Connect, é NECESSÁRIO.
`scope`	REQUERIDO	Na RFC 6749, este parâmetro de solicitação é OPCIONAL. Mas no OpenID Connect, ele é NECESSÁRIO e deve conter `openid`.
`state`	RECOMENDADO	O mesmo requisito que rfc 6749.
`response_mode`	OPCIONAIS	Um novo parâmetro de solicitação definido em OAuth 2.0 Práticas de codificação do tipo de resposta múltipla. Este parâmetro de solicitação especifica como o resultado da solicitação de autorização deve ser formatado.
`nonce`	OPCIONAIS	Um novo parâmetro de solicitação. Um valor de sequência opaco que será incorporado em um token ID. Se `response_type` parâmetro de solicitação contém `id_token` (o que significa que um token de ID é emitido usando fluxo implícito), `nonce` é NECESSÁRIO.
`display`	OPCIONAIS	Um novo parâmetro de solicitação para especificar como a interface do usuário deve ser exibida para o usuário final.
`prompt`	OPCIONAIS	Um novo parâmetro de solicitação para especificar se o serviço deve solicitar ao usuário final a re autenticação e consentimento.
`max_age`	OPCIONAIS	Um novo parâmetro de solicitação para especificar a idade máxima de autenticação.
`ui_locales`	OPCIONAIS	Um novo parâmetro de solicitação para especificar idiomas e scripts preferidos para a interface do usuário.
`id_token_hint`	OPCIONAIS	Um novo parâmetro de solicitação para especificar o token de ID anteriormente emitido pelo serviço.
`login_hint`	OPCIONAIS	Um novo parâmetro de solicitação para especificar uma dica sobre o identificador de login que o usuário final pode usar.
`acr_values`	OPCIONAIS	Um novo parâmetro de solicitação para especificar ACRs (Referências de Classe de Contexto de Autenticação) um dos quais o aplicativo do cliente solicita ser satisfeito.
`claims_locales`	OPCIONAIS	Um novo parâmetro de solicitação para especificar os locais preferidos do usuário final para reivindicações de token de identificação. Este parâmetro de solicitação é definido em OpenID Connect Core 1.0, 5.2. Idiomas e scripts de sinistros.
`claims`	OPCIONAIS	Um novo parâmetro de solicitação para especificar alegações específicas de que o aplicativo do cliente solicita ser incorporado no token ID devolvido. Este parâmetro de solicitação é definido em OpenID Connect Core 1.0, 5.5. Solicitando reclamações usando o parâmetro de solicitação de “sinistros”.
`request`	OPCIONAIS	Um novo parâmetro de solicitação para especificar um objeto de solicitação, que é um JWT embalando outros parâmetros de solicitação e sendo assinado e opcionalmente criptografado. Este parâmetro de solicitação é definido em Abraid Connect Core 1.0, 6. Passando parâmetros de solicitação como JWTs.
`request_uri`	OPCIONAIS	Um novo parâmetro de solicitação para especificar a localização de um objeto de solicitação. Este parâmetro de solicitação é definido em Abraid Connect Core 1.0, 6. Passando parâmetros de solicitação como JWTs.
`registration`	OPCIONAIS	Um novo parâmetro de solicitação para fornecer informações adicionais de registro sobre o próprio aplicativo do cliente. Este parâmetro de solicitação é definido em OpenID Connect Core 1.0, 7.2.1. Fornecendo informações com o parâmetro de solicitação de “registro”.
`code_challenge`	CONDICIONADA	Um novo parâmetro de solicitação para especificar um desafio de código como uma contramedida contra o ataque de interceptação de código. Este parâmetro de solicitação é definido em RFC 7636 (Chave de prova para troca de código por clientes públicos da OAuth). As implementações do servidor de autorização podem sempre exigir este parâmetro para solicitações de autorização usando Fluxo de Código de Autorização. Consulte “Chave de Prova para Troca de Código (RFC 7636)” para obter detalhes.
`code_challenge_method`	OPCIONAIS	Um novo parâmetro de solicitação para dizer o método usado para gerar um desafio de código. Este parâmetro de solicitação é definido em RFC 7636 (Chave de prova para troca de código por clientes públicos da OAuth). Os valores válidos são `plain` (padrão) e `S256`. Consulte “Chave de Prova para Troca de Código (RFC 7636)” para obter detalhes.

Resposta de autorização

1. Parâmetros de resposta

De acordo com RFC 6749, sobre o sucesso, o ponto final de autorização emite um código de autorização ou um token de acesso.

OpenID Connect adicionou outro objeto que pode ser retornado do ponto final da autorização (e/ou do ponto final do token). É um Token de ID. Núcleo de conexão OpenID 1.0 “A extensão primária que o OpenID Connect faz ao OAuth 2.0 para permitir que os usuários finais sejam autenticados é a estrutura de dados do ID Token.” (um trecho de “AbraID Connect Core 1.0, 2. ID Token”).

Resumos curtos dos objetos são os seguintes.

Table. Obejects Returned from the Authorization Endpoint

Código de Autorização	Acess token	ID token
Uma sequência ou número opaco que é uma espécie de bilhete de curta duração a ser trocado com um token de acesso no ponto final do token.	Uma sequência ou número opaco que denota quem (usuário final) concedeu quais permissões (escopos) para qual aplicativo cliente. (Um token de acesso emitido usando Fluxo de credenciais do cliente não tem informações sobre quem.)	Um JWT que contém informações sobre o usuário final.

Antes do OpenID Connect, era um mundo simples onde o ponto final de autorização retornava um código de autorização ou um token de acesso. Não os dois. No entanto, após o OpenID Connect, o ponto final de autorização retorna no máximo todos os três objetos, dependendo do valor de response_type solicitar parâmetro. A tabela a seguir ilustra a relação entre response_type e objetos devolvidos.

Table. The Relationship Between response_type and Returned Objects

response_type	Returned Objects
response_type	Authorization Code	Access Token	ID Token
`none`
`code`
`token`
`id_token`
`code token`
`code id_token`
`id_token token`
`code id_token token`

Em uma resposta do ponto final da autorização, um código de autorização, um token de acesso e um token de ID são incorporados usando code key, access_token chave e id_token chave, respectivamente. Por exemplo code=SplxlOBe em uma resposta significa que o valor do código de autorização é SplxlOBe.

Os parâmetros de resposta que podem ser retornados do ponto final da autorização são os seguintes.

Table. Response Parameters From The Authorization Endpoint

No.	Name	Description
1	`code`	An authorization code issued to the client application. This is contained in a successful response when `response_type` request parameter of the authorization request contained `code`.
2	`access_token`	An access token issued to the client application. This is contained in a successful response when `response_type` request parameter of the authorization request contained `token`.
3	`id_token`	An ID token issued to the client application. This is contained in a successful response when `response_type` request parameter of the authorization request contained `id_token`.
4	`state`	When an authorization request contains `state` request parameter, the authorization endpoint includes the parameter in the authorization response without changing the value.
5	`error`	An error code. This is contained in a response when an error occurred.
6	`error_description`	The short description of the error which happened. This may be contained in a response when an error occurred.
7	`error_uri`	The URI where the detailed description of the error can be found. This may be contained in a response when an error occurred.
8	`token_type`	The token type of the access token. This is contained in a successful response when `response_type` request parameter of the authorization request contained `token`.
9	`expires_in`	The lifetime in seconds of the access token. This may be contained in a successful response when `response_type` request parameter of the authorization request contained `token`.
10	`scope`	A space-delimited scope list of the access token. This may be contained in a successful response when `response_type` request parameter of the authorization request contained `token`.

2. Formato de resposta

De acordo com RFC 6749, tanto no Fluxo de Código de Autorização quanto no Fluxo Implícito, o status HTTP de uma resposta bem sucedida do ponto final da autorização é “302 Encontrado”, que aciona o agente do usuário (= o navegador da Web que o usuário final está usando) para ser redirecionado para outro local a partir do ponto final da autorização. Em OAuth 2.0, o local de destino é chamado redirecionar URI.

Os parâmetros de resposta são devolvidos à aplicação do cliente como parte do URI redirecionado. Por exemplo, se (1) o fluxo for O Fluxo do Código de Autorização, (2) o URI redirecionado será https://client.example.org/callback, e (3) o valor do código de autorização é ap8uacb2, a resposta do ponto final de autorização para o aplicativo do cliente será semelhante ao seguinte.

HTTP/1.1 302 Found
Location: https://client.example.org/callback?code=ap8uacb2
Cache-Control: no-store
Pragma: no-cache

Outro exemplo. Se o fluxo for Fluxo Implícito e o valor do token de acesso for pqb8u3t, a resposta será semelhante ao seguinte (com quebras de linha extras apenas para fins de exibição).

HTTP/1.1 302 Found
Location: https://client.example.org/callback#access_token=pqb8u3t
                                             &token_type=Bearer
                                             &expires_in=3600
Cache-Control: no-store
Pragma: no-cache

Você deve ter notado que os parâmetros de resposta no Fluxo de Código de Autorização estão incorporados no componente de consulta (= a parte após ‘?’) mas aqueles em Fluxo Implícito estão incorporados no componente fragmento (= a parte após ‘#’). Essa diferença é um requisito da RFC 6749. Em ambos os casos, “302 Encontrado” é usado. A tabela a seguir resume a relação entre response_type e localização dos parâmetros de resposta.

Table. Relationship Between response_type And Response Parameter's Location

response_type	status HTTP	localização dos parâmetros de resposta
code	302	Embutido no componente de consulta do URI redirecionar no cabeçalho Localização.
token	302	Embutido no componente fragmento do URI redirecionar no cabeçalho Localização.

No entanto, OpenID Connect, para ser exato, OAuth 2.0 Form Post Response Mode, acrescentou algumas complexidades aqui. Ele introduziu um mecanismo para controlar o formato de resposta e acrescentou “200 OK” com um HTML como um novo formato de resposta. Este formato é usado quando uma solicitação de autorização vem junto com response_mode=form_post. A seguir, um trecho da especificação (com quebras de linha extras apenas para fins de exibição).

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

<html>
  <head><title>Submit This Form</title></head>
  <body onload="javascript:document.forms[0].submit()">
    <form method="post" action="https://client.example.org/callback">
      <input type="hidden" name="state" value="DcP7csa3hMlvybERqcieLHrRzKBra"/>
      <input type="hidden" name="id_token"
        value="eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiw
        iYXVkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLC
        Jpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0OjkwMzEiLCJpYXQiOjEzNjM5M
        DMxMTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2FlUlRHVE1B
        SnllRE1OOUlKYmdpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0F
        NTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZCIsImF1dGhfdGltZSI6MTM2Mz
        kwMDg5NH0.c9emvFayy-YJnO0kxUNQqeAoYu7sjlyulRSNrru1ySZs2qwqq
        wwq-Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfrpAuiNuEHII-_fk
        IufbGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcq
        XVEKhtPadj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_h
        nrQ5IKXuNsQ1g9ccT5DMtZSwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc
        0uVAwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNRe0iKb47XRXaoz5acA"/>
    </form>
  </body>
</html>

No HTML acima, o redirecionamento URI é definido como o valor de action atributo do form parâmetros de tag e resposta como parâmetros ocultos. Você pode encontrar dois parâmetros de resposta, ou seja, state e id_token. (Neste exemplo, nenhum dos dois code nem access_token está incorporado.)

Depois que o HTML acima é carregado pelo agente do usuário, o JavaScript escrito no atributo de carga da tag corporal é executado. Como resultado, é realizado o redirecionamento para o URI redirecionado.

A tabela abaixo ilustra a relação entre combinações de response_type & response_mode e a localização dos parâmetros de status & resposta HTTP. Observe que o componente de consulta não é utilizável quando um token de acesso e/ou um token de ID estão contidos na resposta.

Table. Relationship Between response_type/response_mode Combinations And HTTP Status/Response Parameters' Location

response_type	response_mode
	(default)	query	fragment	form_post
	302 Found			200 OK
`none`	Query component	Query component	Fragment component	Hidden parameters
`code`	Query component	Query component	Fragment component	Hidden parameters
`token`	Fragment component	NOT ALLOWED	Fragment component	Hidden parameters
`id_token`
`code token`
`code id_token`
`id_token token`
`code id_token token`

3. Resposta de erro

Quando um erro ocorre enquanto um serviço está processando uma solicitação de autorização, o serviço retorna uma resposta de erro ao aplicativo do cliente. Se o URI redirecionado ao qual o erro deve ser relatado tiver sido determinado antes do erro ocorrer, o URI redirecionado pode ser usado.

Quando um URI redirecionado pode ser usado, o error o parâmetro de resposta está sempre incorporado. Além disso, o error_description parâmetro de resposta e o error_uri o parâmetro de resposta pode ser opcionalmente incorporado. Por exemplo, uma resposta de erro se parece com a seguinte. (quebras de linha extras apenas para fins de exibição)

HTTP/1.1 302 Found
Location: https://client.example.org/callback?error=access_denied
  &error_description=The%20end-user%20denied%20the%20authorization%20request.
Cache-Control: no-store
Pragma: no-cache

RFC 6749 define valores do parâmetro de resposta a erros que podem ser devolvidos do ponto final da autorização em 4.1.2.1. Resposta de erro (para fluxo de código de autorização) e em 4.2.2.1. Resposta de erro (para Fluxo Implícito). OpenID Conecte o núcleo 1.0 valores adicionados em 3.1.2.6. Resposta de erro de autenticação. A tabela abaixo agrega os códigos de erro em ordem alfabética.

Table. Values of error from the Authorization Endpoint

Valor	RFC 6749	ID token
access_denied
account_selection_required
consent_required
interaction_required
invalid_request
invalid_request_object
invalid_request_uri
invalid_scope
login_required
registration_not_supported
request_not_supported
request_uri_not_supported
server_error
temporarily_unavailable
unauthorized_client
unsupported_response_type

4. Quando o URI redirecionar não está disponível

Erros podem ocorrer antes que o redirecionamento URI seja determinado. Por exemplo, se o ID do cliente especificado (client_id) é inválido, é impossível verificar se o redirecionamento especificado URI (redirect_uri) foi registrado ou não, portanto, o erro não pode ser relatado ao redirecionamento uri.

RFC 6749, 3.1.2.4. Ponto final inválido Diz:

Se uma solicitação de autorização falhar na validação devido a um URI de redirecionamento ausente, inválido ou incompatível, o servidor de autorização deverá informar o proprietário do recurso do erro e NÃO deve redirecionar automaticamente o usuário-agente para o URI de redirecionamento inválido.

mas os meios sobre como informar o proprietário do recurso (= usuário final) do erro não são descritos em lugar nenhum. Portanto, o ponto final da autorização tem que decidir o seu caminho. A seguir, alguns candidatos de formatos de resposta.

http status	do tipo de conteúdo	Comentario
400	de solicitação ruim `text/html`	O erro é descrito no formato HTML e mostrado no agente do usuário. Isso é amigável para usuários finais e testadores.
400	de solicitação ruim `application/json`	O erro é descrito no formato JSON da mesma forma que o ponto final do token (RFC 6749, 5.2. Resposta de erro). Isso é amigável para desenvolvedores de aplicativos de clientes.

Considerando que o OpenID Connect adicionou um caso de uso (prompt=none) onde nenhuma interação do usuário é realizada, application/json pode ser melhor.

Interação de Autorização

1. Finalidade de Autorização

A tarefa principal de um ponto final de autorização é permitir que um usuário final conceda autorização a um aplicativo cliente. No caso normal, isso é conseguido exibindo uma página HTML que

mostra informações sobre o aplicativo do cliente e as permissões solicitadas (escopos),
fornece um formulário de login para autenticar o usuário final e
dois botões para o usuário final decidir “autorizar” ou “negar” a solicitação de autorização.

O formulário a seguir mostra um conjunto mínimo típico de componentes de interface do usuário que um ponto final de autorização exibe.

OAuth é uma estrutura para autorização, mas não para autenticação. Como declarado em RFC 6749, 3.1. Endpoint de autorização, “A forma como o servidor de autorização autentica o proprietário do recurso (por exemplo, nome de usuário e login de senha, cookies de sessão) está além do escopo de " OAuth. Seja como for, é certo que o usuário final deve ser autenticado no ponto final da autorização, pois um token de acesso deve ser associado a um proprietário de recursos (exceto no caso de Concessão de Credenciais do Cliente).

Desde RFC 6749 menciona quase nada sobre autenticação do usuário final, os implementadores implementaram-no como quisessem. No entanto, o OpenID Connect adicionou alguns mecanismos para controlar a autenticação do usuário final. As seguintes subseções as descrevem.

2. `prompt` Parâmetro de solicitação

O opcional prompt o parâmetro de solicitação especifica “se o Servidor de Autorização solicita ao Usuário Final a reautorização e consentimento”. (OpenID Connect Core 1.0, 3.1.2.1. Solicitação de autenticação)

Seu valor é uma combinação delimitada pelo espaço de login, consent e select_account ou nenhum, que não deve ser combinado com outros valores. A tabela a seguir explica os requisitos dos valores.

| Valor | | de descrição | — | — | | login | Quando prompt Contém login, o usuário final deve ser autenticado mesmo quando já fez login. | | consent | Quando prompt Contém consent, o consentimento deve ser obtido do usuário final mesmo quando a implementação do ponto final da autorização sabe que o consentimento foi obtido no passado. | | select_account | Quando prompt Contém select_account, a implementação do ponto final de autorização deve prompt o usuário final para selecionar uma conta de usuário. | | none | Quando prompt É none, a implementação do ponto final da autorização deve processar a solicitação de autorização sem exibir qualquer interface do usuário (= sem interação do usuário). |

A implementação mais simples para uma combinação de login, consent e select_account é sempre exibir um formulário com campos de entrada para ID de login e senha. Mas, não é o caso se o método de autenticação no ponto final da autorização for diferente do típico por ID & senha (por exemplo, no caso de autenticação biométrica por impressões digitais).

3. Referência de classe de contexto de autenticação

Referência de classe de contexto de autenticação, que também é referido como ACR nas especificações OpenID Connect, é uma string que representa um conjunto de contexto, nível e/ou outros atributos de um método de autenticação. Por exemplo urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport representa o método de autenticação que é realizado apresentando uma senha em uma sessão protegida. (Este exemplo é um trecho de Contexto de autenticação para o OASIS Security Assertion Markup Language (SAML) V2.0.)

Núcleo de conexão OpenID 1.0 não mostra nenhum valor ACR concreto que não seja “0”. Em vez disso, ele apenas diz que as partes que usam valores ACR (ou seja, o servidor OAuth e o aplicativo do cliente) “precisa concordar com os significados dos valores utilizados”. (AbraID Connect Core 1.0, 2. ID Token, acr)

3.1 `acr_values` Parâmetro de solicitação

Uma solicitação de autorização pode ter o acr_values parâmetro de solicitação (OpenID Connect Core 1.0, 3.1.2.1. Solicitação de Autenticação, acr_values) especificar uma lista de ACRs na ordem preferencial. Quando o parâmetro de solicitação estiver contido, a implementação do ponto final da autorização deve satisfazer um deles para autenticação do usuário final.

3.2 `acr` Reivindicação Em `claims` Parâmetro de solicitação

Há outra maneira de apresentar uma lista de ACRs. Ele pode ser feito incluindo o acr reivindicar no valor do claims solicitar parâmetro. O JSON a seguir é um exemplo de um valor do claims parâmetro de solicitação (trecho de OpenID Connect Core 1.0, 5.5. Solicitando reclamações usando o parâmetro de solicitação de “sinistros”).

{
  "userinfo":
    {
      "given_name": {"essential": true},
      "nickname": null,
      "email": {"essential": true},
      "email_verified": {"essential": true},
      "picture": null,
      "http://example.info/claims/groups": null
    },
  "id_token":
    {
      "auth_time": {"essential": true},
      "acr": {"values": ["urn:mace:incommon:iap:silver"] }
    }
}

A exigência de ACR pode ser marcada como “essencial” apenas através do claims solicitar parâmetro.

{
  "id_token":
    {
      "acr":
        {
          "essential": true,
          "values": ["urn:mace:incommon:iap:silver"]
        }
    }
}

Se o acr reivindicação é solicitado como essencial, um dos ACRs listados em values deve estar satisfeito. Se nenhum deles puder ser satisfeito, a implementação do ponto final da autorização deve retornar uma resposta de erro ao aplicativo do cliente. Ver OpenID Connect Core 1.0, 5.5.1.1. Solicitando a reivindicação “acr” para detalhes.

3.3 `acr` Reivindicação no ID Token

O acr reivindicação é uma reivindicação opcional que pode ser incorporada em um token de ID. Veja “AbraID Connect Core 1.0, 2. ID Token, acr”, para detalhes.

3.4 ACRs suportados

“OpenID Connect Discovery 1.0, 3. Metadados do provedor OpenID” lista atributos de um provedor OpenID. Entre eles, o acr_values_supported metadados contêm uma lista de ACRs suportados pelo provedor OpenID. Em Authlete, o equivalente é o supportedAcrs propriedade de Serviço.

3.5 ACRs padrão

“OpenID Conectar Registro Dinâmico do Cliente 1.0, 2. Metadados do Cliente” lista atributos de um aplicativo de cliente. Entre eles, o default_acr_values metadados contêm uma lista dos ACRs padrão do aplicativo do cliente que devem ser usados quando uma solicitação de autorização do aplicativo cliente não tem valores ACR explicitamente (pelo acr_values parâmetro de solicitação ou pelos valores do acr reivindicação no claims parâmetro de solicitação). Em Authlete, o equivalente é o defaultAcrs propriedade de Cliente.

4 Idade máxima de autenticação

Idade máxima de autenticação é “o tempo permitido em segundos desde a última vez que o Usuário Final foi ativamente autenticado” (OpenID Connect Core 1.0, 3.1.2.1. Solicitação de Autenticação, max_age). Se o tempo decorrido for maior do que a idade máxima de autenticação, o usuário final deve ser re-autenticado mesmo que já tenha logado.

4.1 `max_age` Parâmetro de solicitação

Uma solicitação de autorização pode ter o max_age solicitar parâmetro para especificar a idade máxima de autenticação.

4.2 Idade máxima de autenticação padrão

O default_max_age atributo listado em “OpenID Conectar Registro Dinâmico do Cliente 1.0, 2. Metadados do Cliente” é a idade máxima de autenticação que é usada quando uma solicitação de autorização do aplicativo do cliente não tem a max_age solicitar parâmetro. Em Authlete, o equivalente é o defaultMaxAge propriedade de Cliente.

5. `sub` reivindicar

Um aplicativo do cliente pode solicitar um assunto específico (= um identificador de usuário final atribuído pelo serviço) a partir do qual o aplicativo do cliente deseja ser concedido autorização especificando o valor para o sub reivindicar. O seguinte é um exemplo de um valor do claims parâmetro de solicitação que contém o sub reivindicar com um valor.

{
  "id_token":
    {
      "sub": {"value": "248289761001"}
    }
}

Quando uma solicitação de autorização solicita um assunto específico, a autenticação do usuário final deve ser realizada para o assunto. Se isso não estiver satisfeito, a implementação do ponto final da autorização deve retornar uma resposta de erro ao aplicativo do cliente. Ver OpenID Connect Core 1.0, 3.1.2.2. Validação de solicitação de autenticação para detalhes.

6. `login_hint` Parâmetro de solicitação

Um aplicativo do cliente pode dar uma dica sobre o identificador de login para o ponto final de autorização usando o login_hint solicitar parâmetro. Por exemplo, um endereço de e-mail pode ser especificado como o valor.

7. `id_token_hint` Parâmetro de solicitação

Um pedido de cliente pode fazer uma solicitação de autorização com o id_token_hint parâmetro de solicitação cujo valor é o token de ID anteriormente emitido pelo servidor de autorização. O servidor de autorização deve retornar uma resposta de erro quando o usuário final identificado pelo token ID for diferente do usuário final que já está autenticado ou como resultado da solicitação.

8. Sem interação

O OpenID Connect introduziu um meio de executar a tarefa no ponto final da autorização sem a interação do usuário. Um aplicativo do cliente pode solicitá-lo incluindo prompt=none no pedido de autorização.

Um pedido de autorização com prompt=none só pode ser processado com sucesso quando todas as condições listadas abaixo estiverem satisfeitas.

Um usuário final já fez login.
Se a idade máxima de autenticação for especificada pelo max_age parâmetro de solicitação ou o default_max_age propriedade dos metadados do cliente, o tempo decorrido desde a última autenticação do usuário final não excede a idade máxima de autenticação.
Se um assunto específico for solicitado pelo sub reivindicar no valor do claims parâmetro de solicitação, o ID de login do usuário final corresponde ao assunto.
Se o acr reivindicação é marcado como essencial no valor do claims parâmetro de solicitação, o método de autenticação satisfaz uma das referências de classe de contexto de autenticação que estão listadas nos valores de propriedade do acr reivindicação).
Se claims são solicitados, o consentimento para eles foram obtidos com antecedência. (Os meios para obter o consentimento estão além da especificação do OpenID Connect.)

Endpoint de autorização (Especificação)