OAuth 2.0 - Guia rápido

OAuth 2.0 - Visão geral

O que é o OAuth 2.0?

OAuth é um protocolo de autorização aberto, que permite acessar os recursos do proprietário do recurso, habilitando os aplicativos clientes em serviços HTTP como Facebook, GitHub, etc. Ele permite o compartilhamento de recursos armazenados em um site em outro site sem usar suas credenciais. Ele usa tokens de nome de usuário e senha.

OAuth 2.0 é desenvolvido pelo IETF OAuth Working Group , publicado em outubro de 2012.

Por que usar o OAuth 2.0?

  • Você pode usar o OAuth 2.0 para ler dados de um usuário de outro aplicativo.

  • Ele fornece o fluxo de trabalho de autorização para a Web, aplicativos de desktop e dispositivos móveis.

  • É um aplicativo Web do lado do servidor que usa código de autorização e não interage com credenciais do usuário.

Recursos do OAuth 2.0

  • OAuth 2.0 é um protocolo simples que permite acessar recursos do usuário sem compartilhar senhas.

  • Ele fornece fluxos de agente do usuário para executar aplicativos clientes usando uma linguagem de script, como JavaScript. Normalmente, um navegador é um agente de usuário.

  • Ele acessa os dados usando tokens em vez de usar suas credenciais e armazena dados no sistema de arquivos on-line do usuário, como conta do Google Docs ou Dropbox.

Vantagens do OAuth 2.0

  • O OAuth 2.0 é um protocolo muito flexível que depende do SSL (Secure Sockets Layer, que garante que os dados entre o servidor da Web e os navegadores permaneçam privados) para salvar o token de acesso do usuário.

  • O OAuth 2.0 conta com SSL, que é usado para garantir os protocolos do setor de criptografia e está sendo usado para manter os dados seguros.

  • Ele permite acesso limitado aos dados do usuário e permite quando os tokens de autorização expiram.

  • Tem capacidade de compartilhar dados para os usuários sem precisar liberar informações pessoais.

  • É mais fácil de implementar e fornece autenticação mais forte.

Desvantagens do OAuth 2.0

  • Se você estiver adicionando mais extensões nas extremidades da especificação, ela produzirá uma ampla variedade de implementações não interoperáveis, o que significa que você deve escrever trechos de código separados para o Facebook, Google etc.

  • Se seus sites favoritos estiverem conectados ao hub central e a conta central for invadida, isso causará sérios efeitos em vários sites, em vez de apenas um.

OAuth 2.0 - Arquitetura

Neste capítulo, discutiremos o estilo arquitetural do OAuth 2.0.

Arquitetura OAuth 2.0

Etapa 1 - Primeiro, o usuário acessa recursos usando o aplicativo cliente, como Google, Facebook, Twitter, etc.

Etapa 2 - Em seguida, o aplicativo cliente receberá o ID do cliente e a senha do cliente durante o registro do URI de redirecionamento (Identificador Uniforme de Recursos).

Etapa 3 - O usuário efetua login usando o aplicativo de autenticação. O ID do cliente e a senha do cliente são exclusivos para o aplicativo cliente no servidor de autorização.

Etapa 4 - O servidor de autenticação redireciona o usuário para um URI (Uniform Resource Identifier) redirecionado usando o código de autorização.

Etapa 5 - O usuário acessa a página localizada no URI de redirecionamento no aplicativo cliente.

Etapa 6 - O aplicativo cliente receberá o código de autenticação, o ID do cliente e a senha do cliente e os enviará ao servidor de autorização.

Etapa 7 - O aplicativo de autenticação retorna um token de acesso ao aplicativo cliente.

Etapa 8 - Depois que o aplicativo cliente obtém um token de acesso, o usuário começa a acessar os recursos do proprietário do recurso usando o aplicativo cliente.

O OAuth 2.0 possui vários conceitos, que são explicados brevemente na tabela a seguir.

Sr. Não. Conceito e descrição
1 Terminologia

OAuth fornece alguns termos adicionais para entender os conceitos de autorização.

2 Servidor web

O servidor Web entrega as páginas da Web e usa HTTP para servir os arquivos que formam as páginas da Web para os usuários.

3 Agente de usuário

O aplicativo agente do usuário é usado pelos aplicativos clientes no dispositivo do usuário, que atua como a instância da linguagem de script.

4 Aplicativo nativo

O aplicativo nativo pode ser usado como uma instância do aplicativo de desktop ou celular, que usa as credenciais de senha do proprietário do recurso.

OAuth 2.0 - credenciais do cliente

As credenciais do cliente podem ser usadas como uma concessão de autorização quando o cliente é o proprietário do recurso ou quando o escopo da autorização é limitado a recursos protegidos sob o controle do cliente.

  • O cliente solicita um token de acesso apenas com a ajuda de credenciais do cliente.

  • O fluxo de autorização de credenciais do cliente é usado para adquirir o token de acesso para autorizar solicitações de API.

  • Usando a autorização de credenciais do cliente, o token de acesso adquirido apenas concede permissão para o seu aplicativo cliente pesquisar e obter documentos do catálogo.

A figura a seguir mostra o fluxo de credenciais do cliente.

Fluxo de credenciais do cliente

O fluxo ilustrado na figura acima consiste nas seguintes etapas -

Etapa 1 - O cliente se autentica no servidor de autorização e solicita o token de acesso a partir do terminal do token.

Etapa 2 - O servidor de autorização autentica o cliente e fornece o token de acesso, se for válido e autorizado.

A tabela a seguir lista os conceitos de credenciais do cliente.

Sr. Não. Conceito e descrição
1 Obtendo autorização do usuário final

O ponto final da autorização normalmente é o URI no servidor de autorização no qual o proprietário do recurso efetua login e permite acessar os dados no aplicativo cliente.

2 Resposta de autorização

A resposta de autorização pode ser usada para obter o token de acesso para acessar os recursos do proprietário no sistema usando o código de autorização.

3 Códigos e resposta a erros

O servidor de autorização responde com códigos de status HTTP 400 ou 401 (solicitação incorreta), se ocorrer um erro durante a autorização.

OAuth 2.0 - Obtendo um token de acesso

Um token de acesso é uma sequência que identifica um usuário, um aplicativo ou uma página. O token inclui informações como quando o token expirará e qual aplicativo criou esse token.

  • Primeiro, é necessário adquirir credenciais do cliente OAuth 2.0 no console da API.

  • Em seguida, o token de acesso é solicitado pelo servidor de autorização pelo cliente.

  • Ele obtém um token de acesso da resposta e envia o token para a API que você deseja acessar.

Você deve enviar o usuário para o terminal de autorização no início. A seguir, é apresentado um exemplo de uma solicitação fictícia

https://publicapi.example.com/oauth2/authorize?client_id=your_client_id&redirect_uri=your_url 
   &response_type=code

A seguir estão os parâmetros e suas descrições.

  • client_id - deve ser definido como o ID do cliente do seu aplicativo.

  • redirect_uri - deve ser definido como o URL. Após a solicitação ser autorizada, o usuário será redirecionado de volta.

  • response_type - Pode ser um código ou um token. O código deve ser usado para aplicativos do lado do servidor, enquanto o token deve ser usado para aplicativos do lado do cliente. Nos aplicativos do lado do servidor, você pode garantir que os segredos sejam salvos com segurança.

A tabela a seguir lista os conceitos de credenciais do cliente.

Sr. Não. Conceito e descrição
1 Código de autorização

O código de autorização permite acessar a solicitação de autorização e concede acesso ao aplicativo cliente para buscar os recursos do proprietário.

2 Credenciais de senha do proprietário do recurso

As credenciais de senha do proprietário do recurso incluem apenas uma solicitação e uma resposta e são úteis quando o proprietário do recurso tem um bom relacionamento com o cliente.

3 Afirmação

A asserção é um pacote de informações que possibilita o compartilhamento de informações de identidade e segurança entre vários domínios de segurança.

4 Atualizar token

Os tokens de atualização são usados para adquirir novos tokens de acesso, que carregam as informações necessárias para obter um novo token de acesso.

5 Resposta de token de acesso

O token de acesso é um tipo de token atribuído pelo servidor de autorização.

6 Códigos de resposta de erro do token de acesso

Se a solicitação de acesso ao token, emitida pelo servidor de autorização, for inválida ou não autorizada, o servidor de autorização retornará uma resposta de erro.

OAuth 2.0 - Acessando um recurso protegido

O cliente fornece um token de acesso ao servidor de recursos para acessar recursos protegidos. O servidor de recursos deve validar e verificar se o token de acesso é válido e não expirou.

Existem duas maneiras padrão de enviar credenciais -

  • Token do portador - O token de acesso pode ser colocado apenas no corpo da solicitação POST ou no parâmetro GET URL como uma opção de fallback no cabeçalho HTTP da autorização.

Eles estão incluídos no cabeçalho da autorização da seguinte maneira -

Authorization: Bearer [token-value]

Por exemplo -

GET/resource/1 HTTP /1.1
Host: example.com
Authorization: Bearer abc...
  • MAC - Um código de autenticação de mensagem (MAC) criptográfico é calculado usando os elementos da solicitação e enviado ao cabeçalho da autorização. Ao receber a solicitação, o MAC é então comparado e computado pelo proprietário do recurso.

A tabela a seguir mostra os conceitos de acesso ao recurso protegido.

Sr. Não. Conceito e descrição
1 Solicitações autenticadas

É usado para obter o token do código de autorização para acessar os recursos do proprietário no sistema.

2 O campo WWW-Authenticate Header Response

O servidor de recursos inclui o campo de cabeçalho de resposta "WWW-Authenticate", se a solicitação de recurso protegido contiver um token de acesso inválido.

OAuth 2.0 - Extensibilidade

Há duas maneiras pelas quais os tipos de token de acesso podem ser definidos -

  • Registrando-se no registro do tipo de token de acesso.

  • Usando um URI absoluto exclusivo (Identificador Uniforme de Recursos) como seu nome.

Definindo novos parâmetros de terminal

Os nomes de parâmetros devem obedecer ao nome de parâmetro ABNF (Augus Backus-Naur Form é uma metalinguagem baseada no Backus-Naur Form que consiste em suas próprias regras de sintaxe e derivação) e a sintaxe dos valores dos parâmetros deve ser bem definida.

param-name = 1* name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA

Definindo novos tipos de concessão de autorização

Novos tipos de concessão de autorização podem ser atribuídos a um URI absoluto distinto para uso, com a ajuda do parâmetro "grant_type". O tipo de concessão de extensão deve ser registrado no registro de parâmetros OAuth, se exigir parâmetros adicionais de terminal de token.

Definindo novos tipos de resposta de terminal de autorização

response-type = response-name *(SP response-name)
response-name = 1* response-char
response-char = "_" / DIGIT / ALPHA

O tipo de resposta é comparado como uma lista de valores delimitada por espaço, se tiver um ou mais caracteres de espaço em que a ordem dos valores não importa e apenas uma ordem de valor puder ser registrada.

Definindo códigos de erro adicionais

Os códigos de erro de extensão devem ser registrados, se as extensões usadas forem um token de acesso registrado ou um parâmetro de terminal registrado. O código de erro deve obedecer ao erro ABNF (Formulário Backus-Naur Aumentado) e, quando possível, deve ser prefixado por um nome que o identifique.

error = 1 * error_char
error-char =  %x20-21 / %x23-5B / 5D-7E

OAuth 2.0 - Considerações da IANA

IANA significa Internet Número de usuários atribuídos à Internet que fornece as informações sobre os valores de registro relacionados ao Serviço de autenticação de autenticação do R Emote (RADIUS).

A IANA inclui as seguintes considerações -

Registro de tipos de token de acesso OAuth

Os tokens de acesso OAuth são registrados por especialistas com as especificações necessárias. Se eles estiverem satisfeitos com o registro, somente eles publicarão a especificação. A solicitação de registro será enviada ao @ ietf.org para revisão com o assunto ("Tipo de token de solicitação de acesso: exemplo"). Os especialistas rejeitarão ou aceitarão a solicitação dentro de 14 dias após a solicitação.

Modelo de Registro

O modelo de registro contém as seguintes especificações -

  • Nome do tipo - é o nome da solicitação.

  • Parâmetros de resposta do terminal de token - O parâmetro de resposta do token de acesso adicional será registrado separadamente no registro de parâmetros do OAuth.

  • Esquema de autenticação HTTP - O esquema de autenticação HTTP pode ser usado para autenticar os recursos usando o token de acesso.

  • Controlador de mudança - forneça o nome do estado como "IETF" para RFCs de faixa padrão e, para outros, use o nome da parte responsável.

  • Documento de especificação - O documento de especificação contém o parâmetro que pode ser usado para recuperar uma cópia do documento.

Registro de parâmetros OAuth

O registro de parâmetros OAuth contém o registro da solicitação ou resposta do terminal de autorização, solicitação ou resposta do terminal do token pelos especialistas com a especificação necessária. A solicitação de registro será enviada aos especialistas e, se estiverem satisfeitos com o registro, eles publicarão a especificação.

Modelo de Registro

O modelo de registro contém especificações como Nome do tipo, Controlador de alterações e Documento de especificação, conforme definido na seção Registro de tipos de token de acesso OAuth acima, exceto a seguinte especificação -

Local de uso do parâmetro - especifica o local do parâmetro, como solicitação ou resposta de autorização, solicitação ou resposta de token.

Conteúdo inicial do registro

A tabela a seguir mostra o registro de parâmetros OAuth que contém o conteúdo inicial -

Sr. Não. Nome do parâmetro e local de uso Controlador de mudança Documento de especificação
1

ID do Cliente

solicitação de autorização, solicitação de token

IETF RFC 6749
2

client_secret

solicitação de token

IETF RFC 6749
3

response_type

author_request

IETF RFC 6749
4

redirect_uri

pedido de autorização, autorização

IETF RFC 6749
5

escopo

solicitação ou resposta de autorização, solicitação ou resposta de token

IETF RFC 6749
6

Estado

solicitação ou resposta de autorização

IETF RFC 6749
7

código

solicitação de token, resposta de autorização

IETF RFC 6749
8

descrição de erro

resposta de autorização, resposta de token

IETF RFC 6749
9

error_uri

resposta de autorização, resposta de token

IETF RFC 6749
10

grant_type

solicitação de token

IETF RFC 6749
11

access_token

resposta de autorização, resposta de token

IETF RFC 6749
12

token_type

resposta de autorização, resposta de token

IETF RFC 6749
13

expira em

resposta de autorização, resposta de token

IETF RFC 6749
14

nome do usuário

solicitação de token

IETF RFC 6749
15

senha

solicitação de token

IETF RFC 6749
16

refresh_token

solicitação de token, resposta de token

IETF RFC 6749

Registro do tipo de resposta do terminal de autorização do OAuth

Isso pode ser usado para definir o Registro do tipo de resposta do terminal de autorização do OAuth. Os tipos de resposta são registrados por especialistas com a especificação necessária e, se estiverem satisfeitos com o registro, somente eles publicarão a especificação. A solicitação de registro será enviada ao @ ietf.org para revisão. Os especialistas rejeitarão ou aceitarão a solicitação dentro de 14 dias após a solicitação.

Modelo de Registro

O modelo de registro contém especificações como Nome do tipo, Controlador de alterações e Documento de especificação, conforme definido na seção Registro de tipos de token de acesso OAuth acima.

Conteúdo inicial do registro

A tabela a seguir mostra o registro do tipo de resposta do terminal de autorização que contém o conteúdo inicial.

Sr. Não. Nome do parâmetro Controlador de mudança Documento de especificação
1 código IETF RFC 6749
2 símbolo IETF RFC 6749

Registro de erro de extensões OAuth

Isso pode ser usado para definir o Registro de erros de extensões do OAuth. Os códigos de erro, juntamente com as extensões de protocolo, como tipos de concessão, tipos de token, etc., são registrados por especialistas com a especificação necessária. Se eles estiverem satisfeitos com o registro, eles publicarão a especificação. A solicitação de registro será enviada ao @ ietf.org para revisão com o assunto ("Pedido de código de erro: exemplo"). Os especialistas rejeitarão ou aceitarão a solicitação dentro de 14 dias após a solicitação.

Modelo de Registro

O modelo de registro contém especificações como Controlador de alterações e Documento de especificação, conforme definido na seção Registro do OAuth Access Token Types , exceto as seguintes especificações -

  • Nome do erro - é o nome da solicitação.

  • Local de uso do erro - especifica o local do erro, como resposta de erro de concessão de código de autorização, resposta implícita de concessão ou resposta de erro de token, etc., que especifica onde o erro pode ser usado.

  • Extensão de protocolo relacionada - Você pode usar extensões de protocolo, como tipo de concessão de extensão, tipo de token de acesso, parâmetro de extensão, etc.