Table of Contents
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.
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.
A RFC 6749 exige que o ponto final da autorização use TLS (Transport Layer Security).
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 |
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.
|
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. |
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 | ||
| 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
|
| 2 | access_token |
An access token issued to the client application. This is
contained in a successful response when
|
| 3 | id_token |
An ID token issued to the client application. This is
contained in a successful response when
|
| 4 | state |
When an authorization request contains |
| 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 |
| 9 | expires_in |
The lifetime in seconds of the access token. This may be
contained in a successful response when
|
| 10 | scope |
A space-delimited scope list of the access token. This may be
contained in a successful response when
|
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 |
||||
token |
Fragment component | NOT ALLOWED | Fragment component | Hidden parameters |
id_token |
||||
code token |
||||
code id_token |
||||
id_token token |
||||
code id_token token |
||||
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 |
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.
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
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.
prompt Parâmetro de solicitaçãoO 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).
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)
acr_values Parâmetro de solicitaçãoUma 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.
acr Reivindicação Em claims Parâmetro de solicitaçãoHá 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.
acr Reivindicação no ID TokenO 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.
“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.
“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.
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.
max_age Parâmetro de solicitaçãoUma solicitação de autorização pode ter o max_age solicitar parâmetro para especificar a idade máxima de autenticaçã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.
sub reivindicarUm 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.
login_hint Parâmetro de solicitaçãoUm 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.
id_token_hint Parâmetro de solicitaçãoUm 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.
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.
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.sub reivindicar no valor do claims parâmetro de solicitação, o ID de login do usuário final corresponde ao assunto.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).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.)