O que é Concessão OAuth 2.0 (OAuth 2.0 grant)?

O que é uma concessão OAuth 2.0 (OAuth 2.0 grant)?

Uma concessão OAuth 2.0 (OAuth 2.0 grant) é um processo de autorização que permite a um Cliente solicitar um Token de acesso (Access token) de um Servidor de autorização . Você também pode ouvir outros termos relacionados a este conceito, então vamos esclarecê-los antes de prosseguir:

• Concessão OAuth 2.0 (OAuth 2.0 grant): Também conhecida como “tipo de concessão OAuth 2.0”, “fluxo OAuth 2.0” ou “concessão de autorização OAuth 2.0”. Na maioria dos contextos, esses termos se referem ao mesmo conceito.
• Servidor de autorização : O servidor que emite access tokens para o cliente. No OpenID Connect (OIDC), o authorization server é o mesmo que o Provedor OpenID (OP) .
• Solicitação de autorização (Authorization request) : A solicitação feita pelo cliente ao authorization server para obter um access token. No OpenID Connect (OIDC), também é referida como uma Solicitação de autenticação (Authentication request) .

Para maior clareza, usaremos os termos iniciais listados acima de forma consistente ao longo deste artigo.

O processo de alto nível de uma concessão OAuth 2.0 (OAuth 2.0 grant) é bastante simples:

Após o cliente receber o access token, ele pode usá-lo para acessar recursos protegidos (por exemplo, APIs) em nome de um usuário ou de si mesmo.

Note que, de acordo com a concessão específica, o cliente e o authorization server podem trocar informações adicionais e envolver mais etapas no processo. Por exemplo, a concessão de código de autorização envolve autenticação e autorização do usuário, geração de código e troca de token.

Diferentes concessões OAuth 2.0 (OAuth 2.0 grants)

A especificação básica do OAuth 2.0 define quatro concessões que os clientes podem usar para obter access tokens:

1. Concessão de código de autorização : A concessão mais segura e recomendada para a maioria das aplicações. É obrigatório usar Chave de Prova para Troca de Código (PKCE) para todos os clientes no OAuth 2.1 .
2. Concessão implícita : Uma concessão simplificada que está obsoleta no OAuth 2.1 devido a preocupações de segurança.
3. Concessão de credenciais de senha do proprietário do recurso (ROPC) : Uma concessão onde as credenciais do usuário são trocadas diretamente por um access token. Não é recomendada para a maioria das aplicações devido a riscos de segurança.
4. Concessão de credenciais do cliente : Uma concessão usada por Clientes confidenciais para obter um access token sem envolvimento do usuário.

À medida que a indústria evolui, as concessões implícitas e ROPC estão sendo descontinuadas em favor de fluxos mais seguros e padronizados. Para novas aplicações, as escolhas são diretas:

• Para autenticação e autorização de usuários, use a concessão de código de autorização com PKCE.
• Para comunicação Comunicação máquina a máquina , use a concessão de credenciais do cliente.

Outras concessões OAuth 2.0 (OAuth 2.0 grants)

Além das quatro concessões básicas, existem outras extensões que definem novas concessões para casos de uso específicos. Por exemplo:

• Concessão de autorização de dispositivo é uma concessão projetada para dispositivos com capacidades de entrada limitadas, como smart TVs e dispositivos IoT.
• Fluxo híbrido é uma concessão do OpenID Connect que combina a concessão de código de autorização com a concessão implícita.

Concessões no OpenID Connect (OIDC)

No OpenID Connect (OIDC) , o conceito de concessões é estendido para incluir ID tokens que representam informações de identidade do usuário além dos access tokens. O OIDC estende duas concessões OAuth 2.0 (código de autorização e implícita) para incluir ID tokens, e introduz uma nova concessão chamada fluxo híbrido que combina ambos.

Assim como no OAuth 2.0, é recomendado usar apenas a concessão de código de autorização com PKCE no OIDC para autenticação e autorização de usuários.

Enquanto isso, como o OIDC é construído sobre o OAuth 2.0, outras concessões como a concessão de credenciais do cliente ainda podem ser usadas no mesmo authorization server, desde que o servidor as suporte.

Veja também

• Chave de Prova para Troca de Código (PKCE)
• OAuth 2.1
• Fluxo de código de autorização (Authorization code flow)
• Fluxo implícito (Implicit flow)
• Fluxo de credenciais do cliente (Client credentials flow)
• Fluxo de dispositivo (Device flow)