Nota do tradutor.: Neste ótimo material da Okta, são explicados de forma simples e clara os princípios de funcionamento do OAuth e OIDC (OpenID Connect). Esse conhecimento será útil para desenvolvedores, administradores de sistema e até mesmo para 'usuários comuns' de populares aplicativos web, que provavelmente também compartilham dados confidenciais com outros serviços.
Na 'era da pedra' da internet, compartilhar informações entre serviços era fácil. Você simplesmente fornecia seu login e senha de um serviço para outro, permitindo que ele acessasse sua conta e obtivesse qualquer informação necessária.
‘Forneça sua conta bancária’. — ‘Prometemos que sua senha e dinheiro estarão seguros. É tudo muito honesto!’ *risos*
Horrível! Ninguém nunca deve exigir que o usuário compartilhe seu login e senha, seus dados de conta, com outro serviço. Não há garantia de que a organização por trás desse serviço manterá os dados seguros e não coletará mais informações pessoais do que o necessário. Isso pode parecer absurdo, mas ainda existem alguns aplicativos que utilizam essa prática!
Hoje existe um padrão único que permite que um serviço acesse dados de outro de forma segura. Infelizmente, esses padrões usam uma quantidade enorme de jargões e termos, o que dificulta a compreensão. O objetivo deste material é explicar como eles funcionam com ilustrações simples (Você acha que meus desenhos parecem rabiscos de criança? Não tem problema!).
A propósito, este guia também está disponível em formato de vídeo:
Senhoras e senhores, apresentamos: OAuth 2.0
— é um padrão de segurança que permite que um aplicativo obtenha permissão para acessar informações em outro aplicativo. O processo para conceder permissão [permission] (ou consentimento [consent]) é frequentemente chamado de autorização [authorization] ou até mesmo autorização delegada [delegated authorization]. Com esse padrão, você permite que um aplicativo acesse dados ou use funções de outro aplicativo em seu nome, sem compartilhar sua senha. Fantástico!
Como exemplo, vamos imaginar que você encontrou um site chamado 'Trocadilho Terrível do Dia' [Terrible Pun of the Day] e decidiram se registrar para receber diariamente trocadilhos em forma de mensagens de texto no celular. Você gostou muito do site e decidiu compartilhá-lo com todos os conhecidos. Afinal, trocadilhos engraçados agradam a todos, não é mesmo?
“Trocadilho infeliz do dia: Ouviram falar do cara que perdeu a metade esquerda do corpo? Agora ele está sempre certo!” (tradução aproximada, pois no original há um jogo de palavras — nota do tradutor.)
É claro que não é viável escrever para cada pessoa da lista de contatos. E, se você for minimamente parecido comigo, fará de tudo para evitar trabalho extra. Felizmente, o Terrible Pun of the Day pode convidar todos os seus amigos sozinho! Para isso, só precisa liberar o acesso ao e-mail de seus contatos — o site enviará os convites automaticamente (OAuth é demais)!
“Todo mundo ama trocadilhos! — Já fez login? — Quer liberar o acesso do site Terrible Pun of the Day à sua lista de contatos? — Obrigado! Agora, todos os dias, enviaremos lembretes a todos os que você conhece, até o fim dos tempos! Você é o melhor amigo!”
- Escolha seu serviço de e-mail.
- Se necessário, acesse o site do e-mail e entre na sua conta.
- Dê permissão para o site Terrible Pun of the Day acessar seus contatos.
- Volte ao site Terrible Pun of the Day.
Caso mude de ideia, os aplicativos que usam OAuth também oferecem uma maneira de cancelar o acesso. Se você decidir que não quer mais compartilhar seus contatos com o Terrible Pun of the Day, pode acessar o site do e-mail e remover o site de trocadilhos da lista de aplicativos autorizados.
Fluxo OAuth
Acabamos de passar pelo que geralmente é chamado de fluxo [flow] OAuth. No nosso exemplo, este fluxo consiste em passos visíveis, além de vários passos invisíveis, onde dois serviços acertam um intercâmbio seguro de informações. No exemplo anterior com o Terrible Pun of the Day, o fluxo OAuth 2.0 mais comum é utilizado, conhecido como fluxo “com código de autorização” [“authorization code” flow].
Antes de nos aprofundarmos nos detalhes de como funciona o OAuth, vamos falar sobre o significado de alguns termos:
- Proprietário do Recurso:
É você! Você possui suas credenciais, seus dados e gerencia todas as ações que podem ser realizadas em suas contas. - Cliente:
Um aplicativo (por exemplo, o serviço Terrible Pun of the Day), que deseja obter acesso ou realizar determinadas ações em nome de Proprietário do Recurso‘a. - Servidor de Autorização:
Um aplicativo que sabe Proprietário do Recurso‘a e no qual Proprietário do Recurso‘a já possui uma conta. - Servidor de Recursos:
Interface de Programação de Aplicações (API) ou serviço que Cliente deseja utilizar em nome de Proprietário do Recurso‘a. - URI de Redirecionamento:
O link para onde Servidor de Autorização redirecionará Proprietário do Recurso‘a após conceder a permissão Cliente‘u. Às vezes, é chamado de 'URL de Retorno' ('Callback URL'). - Tipo de Resposta:
O tipo de informação que se espera receber Cliente. O mais comum Tipo de Resposta‘om é o código, ou seja, Cliente pretende obter Código de Autorização. - Escopo:
Esta é uma descrição detalhada das permissões que são exigidas Cliente‘u, como acesso a dados ou a execução de determinadas ações. - Consentimento:
Servidor de Autorização obtém Escopos, solicitados Cliente‘om, e pergunta a Proprietário do Recurso‘a se está disposto a conceder Cliente‘u as permissões correspondentes. - ID do Cliente:
Este ID é usado para identificar Cliente‘a na Servidor de Autorização‘e. - Segredo do Cliente:
Esta é uma senha que é conhecida apenas por Cliente‘u e Servidor de Autorização‘u. Permite que eles troquem informações confidencialmente. - Código de Autorização:
Um código temporário com um pequeno período de validade que Cliente fornece Servidor de Autorização‘u em troca de Token de Acesso. - Token de Acesso:
Uma chave que o cliente usará para se comunicar com Servidor de Recursos‘om. Uma espécie de crachá ou chave que fornece a Cliente‘u permissões para solicitar dados ou executar ações em Servidor de Recursos‘e em seu nome.
Nota: às vezes, o Servidor de Autorização e o Servidor de Recursos são o mesmo servidor. No entanto, em alguns casos, eles podem ser servidores diferentes, pertencentes a organizações distintas. Por exemplo, o Servidor de Autorização pode ser um serviço de terceiros confiável pelo Servidor de Recursos.
Agora que nos familiarizamos com os conceitos básicos do OAuth 2.0, vamos voltar ao nosso exemplo e detalhar o que acontece no fluxo do OAuth.
- Você, Proprietário do Recurso, deseja conceder ao serviço Terrible Pun of the Day (Cliente‘u) acesso a seus contatos, para que ele possa enviar convites a todos os seus amigos.
- Cliente redireciona o navegador para a página Servidor de Autorização‘a e inclui na solicitação ID do Cliente, URI de Redirecionamento, Tipo de Resposta uma ou mais Escopos (permissões) que são necessárias.
- Servidor de Autorização verifica você, pedindo, se necessário, login e senha.
- Servidor de Autorização mostra um formulário Consentimento (de confirmação) com a lista de todas as Escopos, solicitadas Cliente‘om. Você concorda ou recusa.
- Servidor de Autorização redireciona você para o site Cliente‘a, usando URI de Redirecionamento junto com Código de Autorização (código de autorização).
- Cliente contata diretamente Servidor de Autorização‘om (contornando o navegador Proprietário do Recurso‘a) e envia de forma segura. ID do Cliente, Segredo do Cliente e Código de Autorização.
- Servidor de Autorização verifica os dados e responde com Token de Acessoum (token de acesso).
- Agora, Cliente pode usar Token de Acesso para enviar a solicitação para Servidor de Recursos com o objetivo de obter uma lista de contatos.
Client ID e Secret
Muito antes de você permitir que o Terrible Pun of the Day acessasse os contatos, o Client e o Authorization Server estabeleceram um relacionamento de trabalho. O Authorization Server gerou o Client ID e o Client Secret (às vezes conhecidos como App ID e App Secret) e os enviou ao Client para interação adicional dentro do OAuth.
— Olá! Eu gostaria de trabalhar com você! — Sem problema! Aqui estão seus Client ID e Secret!”
O nome sugere que o Client Secret deve ser mantido em segredo, para que só o Client e o Authorization Server o conheçam. Afinal, é com sua ajuda que o Authorization Server confirma a autenticidade do Client.
Mas isso ainda não é tudo… Por favor, dê as boas-vindas ao OpenID Connect!
OAuth 2.0 é projetado apenas para de autorização — fornecer acesso a dados e funções de um aplicativo para outro. (OIDC) é uma camada fina sobre o OAuth 2.0, adicionando informações sobre o login e o perfil do usuário que entrou na conta. A organização da sessão de login é frequentemente chamada de autenticação [authentication], e as informações sobre o usuário que fez login (ou seja, sobre Proprietário do Recursoele), — dados pessoais [identity]. Se o Authorization Server suporta OIDC, às vezes é chamado de provedor de identidade [identity provider], pois fornece Clientea informação sobre Proprietário do Recurso‘e.
OpenID Connect permite implementar cenários onde um único login pode ser usado em vários aplicativos, — essa abordagem também é conhecida como single sign-on (SSO). Por exemplo, um aplicativo pode suportar integração SSO com redes sociais como Facebook ou Twitter, permitindo que os usuários usem uma conta que já possuem e preferem usar.
O fluxo OpenID Connect é semelhante ao do OAuth. A única diferença é que na solicitação inicial, o escopo específico utilizado é openid, — e Cliente no final obtém como Token de Acesso, quanto o ID Token.
Assim como no fluxo OAuth, Token de Acesso no OpenID Connect — é um valor, não compreendido por Clienteele. Do ponto de vista de Clienteele Token de Acesso representa uma certa string de caracteres, que é passada com cada solicitação para Servidor de Recursosele, e este determina se o token é válido. ID Token representa algo completamente diferente.
ID Token — é um JWT
ID Token — é uma string formatada de maneira especial, conhecida como JSON Web Token ou JWT (às vezes os tokens JWT são pronunciados como “jots”). Para um observador externo, o JWT pode parecer um tipo de abracadabra incompreensível, porém Cliente ele pode extrair diversas informações do JWT, como ID, nome de usuário, hora de login, e data de expiração ID Token‘e a existência de tentativas de interferência no JWT. Os dados dentro ID Token‘são chamados de declarações [claims].
No caso do OIDC, também existe uma maneira padrão pela qual Cliente pode solicitar informações adicionais sobre a identidade [identity] de Servidor de Autorização‘como, por exemplo, um endereço de e-mail, utilizando Token de Acesso.
Mais informações sobre OAuth e OIDC
Assim, revisamos brevemente os princípios de funcionamento do OAuth e OIDC. Pronto para se aprofundar? Aqui estão recursos adicionais que ajudarão você a saber mais sobre OAuth 2.0 e OpenID Connect:
Como sempre, sinta-se à vontade para comentar. Para ficar por dentro das nossas últimas novidades, siga a e empresa Okta para desenvolvedores!
P.S. do tradutor
Confira também em nosso blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
