Observação. trad.: Este ótimo artigo da Okta explica como o OAuth e o OIDC (OpenID Connect) funcionam de maneira simples e clara. Esse conhecimento será útil para desenvolvedores, administradores de sistema e até mesmo "usuários regulares" de aplicativos da Web populares, que provavelmente também trocam dados confidenciais com outros serviços.
Na Idade da Pedra da Internet, compartilhar informações entre serviços era fácil. Você simplesmente deu seu login e senha de um serviço para outro, para que ele entrasse na sua conta e recebesse todas as informações que precisasse.
"Dê-me sua conta bancária." “Prometemos que tudo ficará bem com a senha e o dinheiro. Isso é honesto, honesto!" *ei hei*
Horror! Ninguém deve exigir que um usuário compartilhe um nome de usuário e senha, credenciais, com outro serviço. Não há garantia de que a organização por trás deste serviço manterá os dados seguros e não coletará mais informações pessoais do que o necessário. Pode parecer loucura, mas alguns aplicativos ainda utilizam essa prática!
Hoje existe um único padrão que permite que um serviço use com segurança os dados de outro. Infelizmente, tais padrões usam muitos jargões e termos, o que dificulta seu entendimento. O objetivo deste material é explicar como eles funcionam usando ilustrações simples (você acha que meus desenhos se assemelham a pintura infantil? Oh bem!).
A propósito, este guia também está disponível em formato de vídeo:
Senhoras e senhores, bem-vindos: OAuth 2.0
é um padrão de segurança que permite que um aplicativo obtenha permissão para acessar informações em outro aplicativo. Sequência de passos para a emissão de uma licença [permissão] (ou consentimento [consentimento]) costuma ligar autorização [autorização] ou autorização delegada [autorização delegada]. Com esse padrão, você permite que um aplicativo leia dados ou use as funções de outro aplicativo em seu nome sem fornecer sua senha. Aula!
Por exemplo, digamos que você descubra um site chamado "Trocadilho azarado do dia" [Terrível trocadilho do dia] e decidiu se cadastrar para receber trocadilhos diários na forma de mensagens de texto no telefone. Você gostou muito do site e decidiu compartilhar com todos os seus amigos. Afinal, todo mundo gosta de trocadilhos assustadores, certo?
“Infeliz trocadilho do dia: ouviu falar do cara que perdeu a metade esquerda do corpo? Agora ele está sempre certo!” (tradução aproximada, porque o original tem seu próprio trocadilho - aprox. trad.)
É claro que escrever para cada pessoa da lista de contatos não é uma opção. E, se você for um pouco como eu, fará de tudo para evitar trabalho desnecessário. Felizmente, o terrível trocadilho do dia pode convidar todos os seus amigos sozinho! Para isso, basta abrir o acesso ao e-mail dos seus contatos - o próprio site enviará os convites (regras OAuth)!
“Todo mundo adora trocadilhos! - Já logado? “Gostaria de permitir que o site Terrible Pun of the Day acesse sua lista de contatos? - Obrigado! A partir de agora, enviaremos lembretes todos os dias para todos que você conhece, até o fim dos tempos! Você é o melhor amigo!"
- Escolha o seu serviço de e-mail.
- Se necessário, acesse o site de e-mail e faça login na sua conta.
- Dê permissão ao terrível trocadilho do dia para acessar seus contatos.
- Retorne ao site do terrível trocadilho do dia.
Caso você mude de ideia, os aplicativos que usam OAuth também fornecem uma maneira de revogar o acesso. Depois de decidir que não deseja mais compartilhar contatos com o terrível trocadilho do dia, você pode acessar o site de e-mail e remover o trocadilho da lista de aplicativos autorizados.
Fluxo OAuth
Acabamos de passar pelo que geralmente é chamado fluxo [fluxo] OAuth. Em nosso exemplo, esse fluxo consiste em etapas visíveis, bem como em várias etapas invisíveis, nas quais dois serviços concordam em uma troca segura de informações. O exemplo anterior do terrível trocadilho do dia usa o fluxo OAuth 2.0 mais comum, conhecido como fluxo de "código de autorização". [fluxo de "código de autorização"].
Antes de mergulhar nos detalhes de como o OAuth funciona, vamos falar sobre o significado de alguns termos:
- Proprietário do recurso:
É você! Você possui suas credenciais, seus dados e controla todas as atividades que podem ser realizadas em suas contas. - Cliente:
Um aplicativo (por exemplo, o terrível trocadilho do dia) que deseja acessar ou executar determinadas ações em nome de Proprietário do recurso'à. - Servidor de Autorização:
O aplicativo que sabe Proprietário do recurso'a e em que você Proprietário do recurso'a já tem uma conta. - Servidor de Recursos:
Interface de programação de aplicativos (API) ou serviço que Cliente quer usar em nome Proprietário do recurso'à. - URI de redirecionamento:
o link que Servidor de Autorização irá redirecionar Proprietário do recurso'e depois de conceder permissão Cliente'no. Às vezes, é chamado de "URL de retorno de chamada". - Tipo de Resposta:
O tipo de informação que se espera receber Cliente. O mais comum Tipo de Resposta'ohm é o código, isto é Cliente espera receber Código de autorização. - Objetivo:
Esta é uma descrição detalhada das permissões necessárias Cliente'y, como acessar dados ou executar determinadas ações. - Consentimento:
Servidor de Autorização leva EscoposRequeridos Cliente'om, e pergunta Proprietário do recurso'a, ele está pronto para fornecer Cliente'ter as permissões apropriadas. - ID do cliente:
Este ID é usado para identificar Cliente'um em Servidor de Autorização'e. - Segredo do cliente:
Esta é a senha que só é conhecida Cliente'você e Servidor de Autorização'no. Isso permite que eles compartilhem informações de forma privada. - Código de autorização:
Código temporário com um curto período de validade, que Cliente fornece Servidor de Autorização'y em troca de token de acesso. - token de acesso:
A chave que o cliente usará para se comunicar com Servidor de Recursos'om. Uma espécie de crachá ou cartão-chave que fornece Cliente'ter permissão para solicitar dados ou executar ações em Servidor de Recursos'e em seu nome.
Nota: Às vezes, o Authorization Server e o Resource Server são o mesmo servidor. No entanto, em alguns casos, podem ser servidores diferentes, mesmo que não pertençam à mesma organização. Por exemplo, o Authorization Server pode ser um serviço de terceiros confiável para o Resource Server.
Agora que abordamos os principais conceitos do OAuth 2.0, vamos voltar ao nosso exemplo e examinar mais de perto o que acontece no fluxo do OAuth.
- Vocês, Proprietário do recurso, você deseja fornecer o serviço Terrível trocadilho do dia (Clientey) acesso aos seus contatos para que eles possam enviar convites para todos os seus amigos.
- Cliente redireciona o navegador para a página Servidor de Autorização'a e incluir na consulta ID do cliente, URI de redirecionamento, Tipo de Resposta e um ou mais Escopos (permissões) de que precisa.
- Servidor de Autorização verifica você, solicitando um nome de usuário e senha, se necessário.
- Servidor de Autorização exibe um formulário Consentimento (confirmações) com uma lista de todos EscoposRequeridos Cliente'om. Você concorda ou recusa.
- Servidor de Autorização redireciona você para o site Cliente'a, usando URI de redirecionamento com Código de autorização (Código de autorização).
- Cliente comunica-se diretamente com Servidor de Autorização'ohm (ignorando o navegador Proprietário do recurso'a) e envia com segurança ID do cliente, Segredo do cliente и Código de autorização.
- Servidor de Autorização verifica os dados e responde com token de acesso'om (token de acesso).
- Agora Cliente pode usar token de acesso enviar um pedido para Servidor de Recursos para obter uma lista de contatos.
ID e segredo do cliente
Muito antes de você permitir que o terrível trocadilho do dia acessasse seus contatos, o cliente e o servidor de autorização estabeleceram uma relação de trabalho. O servidor de autorização gerou o ID do cliente e o segredo do cliente (às vezes chamado app ID и Segredo do aplicativo) e os enviou ao cliente para interação posterior no OAuth.
"- Olá! Eu gostaria de trabalhar com você! - Claro, sem problemas! Aqui estão o seu ID e Segredo do Cliente!”
O nome implica que o segredo do cliente deve ser mantido em segredo para que apenas o cliente e o servidor de autorização o conheçam. Afinal, é com a ajuda dele que o Authorization Server confirma a veracidade do Cliente.
Mas isso não é tudo... Dê as boas-vindas ao OpenID Connect!
OAuth 2.0 foi projetado apenas para autorização - para fornecer acesso a dados e funções de um aplicativo para outro. (OIDC) é uma camada fina sobre o OAuth 2.0 que adiciona os detalhes de login e perfil do usuário que está conectado à conta. A organização de uma sessão de login é muitas vezes referida como autenticação [autenticação], e informações sobre o usuário logado no sistema (ou seja, sobre Proprietário do recurso'e), - dados pessoais [identidade]. Se o Authorization Server for compatível com OIDC, às vezes ele é chamado de provedor de dados pessoais [provedor de identidade]porque fornece Cliente'tem informações sobre Proprietário do recurso'e.
O OpenID Connect permite implementar cenários em que um único login pode ser usado em vários aplicativos - essa abordagem também é conhecida como logon único (SO). Por exemplo, um aplicativo pode oferecer suporte à 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 (fluxo) do OpenID Connect tem a mesma aparência do caso do OAuth. A única diferença é que na solicitação principal, o escopo específico usado é openid, - A Cliente eventualmente fica como token de acessoE token de identificação.
Assim como no fluxo OAuth, token de acesso no OpenID Connect, este é algum valor que não está claro Cliente'no. Do ponto de vista Cliente'а token de acesso representa uma cadeia de caracteres que é passada junto com cada solicitação para Servidor de Recursos'y, que determina se o token é válido. token de identificação representa uma coisa completamente diferente.
Token de ID é um JWT
token de identificação é uma cadeia de caracteres especialmente formatada conhecida como JSON Web Token ou JWT (às vezes, os tokens JWT são pronunciados como "jots"). Para observadores externos, JWT pode parecer um jargão incompreensível, mas Cliente pode extrair várias informações do JWT, como ID, nome de usuário, horário de login, data de expiração token de identificação'a, a presença de tentativas de interferir no JWT. Dados dentro token de identificação'um são chamados formulários [reivindicações].
No caso do OIDC, também existe uma forma padrão pela qual Cliente pode solicitar informações adicionais sobre o indivíduo [identidade] de Servidor de Autorização'a, por exemplo, um endereço de e-mail usando token de acesso.
Saiba mais sobre OAuth e OIDC
Portanto, revisamos brevemente como o OAuth e o OIDC funcionam. Pronto para cavar mais fundo? Aqui estão recursos adicionais para ajudá-lo a aprender mais sobre OAuth 2.0 e OpenID Connect:
Como sempre, fique à vontade para comentar. Para manter-se atualizado com nossas últimas notícias, assine и Okta para desenvolvedores!
PS do tradutor
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com