Nota perev. : Este excelente post no Okta explica como OAuth e OIDC (OpenID Connect) funcionam. Esse conhecimento será útil para desenvolvedores, administradores de sistema e até mesmo "usuários comuns" de aplicativos populares da Web que provavelmente também trocam dados confidenciais com outros serviços.Na Idade da Pedra da Internet, era fácil compartilhar informações entre serviços. Você simplesmente forneceu seu nome de usuário e senha de um serviço para outro, para que ele entrasse em sua conta e recebesse as informações necessárias.
"Forneça sua conta bancária." “Prometemos que tudo ficará bem com a senha e o dinheiro. Isso é honestamente honesto! ”* Hee hee *Horror! Ninguém deve exigir que um usuário compartilhe seu nome de usuário e senha, suas
credenciais com outro serviço. Não há garantia de que a organização por trás desse serviço mantenha os dados seguros e não colete mais informações pessoais do que o necessário. Pode parecer selvagem, mas alguns aplicativos ainda usam essa prática!
Hoje existe um único padrão que permite que um serviço use com segurança os dados de outro. Infelizmente, esses padrões usam muito jargão e termos, o que complica sua compreensão. O objetivo deste material é explicar como eles funcionam com ilustrações simples (você acha que meus desenhos se assemelham a um bebê fofo? Bem, tudo bem!).
A propósito, este guia também está disponível em formato de vídeo:
Senhoras e senhores, conheçam: OAuth 2.0
OAuth 2.0 é um padrão de segurança que permite que um aplicativo obtenha permissão para acessar informações em outro aplicativo. A sequência de etapas para emitir uma permissão
(permissão ) costuma ser chamada de
autorização ou mesmo
autorização delegada . Usando esse padrão, você permite que um aplicativo leia dados ou use as funções de outro aplicativo em seu nome sem informar sua senha. Classe!
Como exemplo, imagine que você descobriu um site chamado "
Terrível trocadilho do dia" e decidiu se registrar nele para receber trocadilhos diariamente na forma de mensagens de texto no telefone. Você realmente gostou do site e decidiu compartilhá-lo com todos os seus amigos. Afinal, trocadilhos terríveis como todo mundo, certo?
"Chalaça malsucedida do dia: você já ouviu falar sobre um 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. Transl.)É claro que escrever para cada pessoa da lista de contatos não é uma opção. E, se você é um pouco como eu, fará de tudo para evitar trabalhos desnecessários. Felizmente Terrível trocadilho do dia pode convidar todos os seus amigos por conta própria! Para fazer isso, você só precisa abrir o acesso aos contatos de e-mail dele - o próprio site envia convites (unidades OAuth)!
"Todo mundo adora trocadilhos!" - Já está logado? - Deseja compartilhar o site Terrível trocadilho do dia com sua lista de contatos? Obrigado! Agora, todos os dias, enviaremos lembretes a todos que você conhece até o final dos tempos! Você é o melhor amigo!- Escolha o seu serviço de email.
- Se necessário, acesse o site de correio e faça login na sua conta.
- Dê permissão Terrible Pun of the Day para acessar seus contatos.
- Retorne ao site Terrível Chalaça do Dia.
Caso você mude de idéia, os aplicativos que usam OAuth também fornecem uma maneira de revogar o acesso. Depois de ter decidido que não deseja mais compartilhar contatos com Terrible Pun of the Day, você pode acessar o site de correio e excluir o site com trocadilhos da lista de aplicativos autorizados.
Fluxo OAuth
Acabamos de passar pelo que é comumente chamado de
fluxo OAuth
[fluxo] . 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 Terrible Pun of the Day usa o fluxo OAuth 2.0 mais comum, conhecido como
fluxo "código de autorização" .
Antes de nos aprofundarmos nos detalhes do 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 executadas com suas contas. - Cliente :
Um aplicativo (por exemplo, o serviço Terrível Chalaça do Dia) que deseja acessar ou executar determinadas ações em nome do Proprietário do Recurso . - Servidor de Autorização :
Um aplicativo que conhece o Proprietário do Recurso e no qual o Proprietário do Recurso já possui uma conta. - Servidor de recursos :
Uma interface de programação de aplicativos (API) ou serviço que um Cliente deseja usar em nome do Proprietário do Recurso . - Redirecionar URI :
O link no qual o Servidor de Autorização redireciona o Proprietário do Recurso para 'depois de conceder permissão do Cliente ' para. Às vezes, é chamado de URL de retorno de chamada. - Tipo de resposta :
O tipo de informação que o Cliente espera receber. O tipo de resposta mais comum é o código, ou seja, o cliente espera receber um código de autorização . - Âmbito :
Esta é uma descrição detalhada das permissões que o Cliente precisa, como acessar dados ou executar determinadas ações. - Consentimento :
O servidor de autorização pega os escopos solicitados pelo cliente e pergunta ao proprietário do recurso se está pronto para conceder ao cliente as permissões apropriadas. - ID do cliente :
Esse ID é usado para identificar o cliente no servidor de autorização . - Segredo do cliente :
Essa é uma senha conhecida apenas pelo Cliente e pelo Servidor de Autorização . Isso lhes permite trocar informações confidencialmente. - Código de autorização :
Um código temporário de curto prazo que o Cliente fornece ao Servidor de Autorização em troca de um Token de Acesso . - Token de acesso :
A chave que o cliente usará para se comunicar com o Servidor de Recursos . Este é um crachá ou cartão-chave que permite ao Cliente solicitar dados ou executar ações no Servidor de Recursos em seu nome.
Nota : às vezes, o Authorization Server e o Resource Server são o mesmo servidor. No entanto, em alguns casos, esses servidores podem ser diferentes, nem mesmo pertencentes à mesma organização. Por exemplo, um servidor de autorização pode ser um serviço de terceiros em que o servidor de recursos confia.
Agora que nos familiarizamos com os conceitos básicos do OAuth 2.0, voltemos ao nosso exemplo e analisemos mais de perto o que acontece no fluxo do OAuth.
- Você, Proprietário do Recurso , deseja fornecer acesso aos seus contatos do Terrível Dia do Dia ( Cliente ) para que ele possa enviar convites para todos os seus amigos.
- O cliente redireciona o navegador para a página Servidor de Autorização e inclui na solicitação o ID do Cliente , URI de Redirecionamento , Tipo de Resposta e um ou mais Escopos (permissões) necessários.
- O Authorization Server verifica você, se necessário, solicitando um nome de usuário e senha.
- O servidor de autorização exibe um formulário de consentimento com uma lista de todos os escopos solicitados pelo cliente . Você concorda ou recusa.
- O Servidor de Autorização o redireciona para o site do Cliente usando o URI de Redirecionamento junto com o Código de Autorização .
- O Cliente se comunica diretamente com o Servidor de Autorização (ignorando o navegador do Proprietário do Recurso ) e envia com segurança o ID do Cliente , o Segredo do Cliente e o Código de Autorização .
- O servidor de autorização valida os dados e responde com um token de acesso .
- Agora o cliente pode usar o token de acesso para enviar uma solicitação ao servidor de recursos para obter uma lista de contatos.
ID do cliente e segredo
Muito antes de você permitir que Terrible Pun of the Day acesse 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 de
ID do Aplicativo e
Segredo do Aplicativo ) e os enviou ao Cliente para interação adicional no OAuth.
Olá! Eu gostaria de trabalhar com você! - Sim, sem dúvida! Aqui estão o seu ID de cliente e segredo! ”O nome sugere que o Segredo do Cliente deve ser mantido em segredo para que apenas o Cliente e o Servidor de Autorização o conheçam. De fato, é com a ajuda dele que o Servidor de Autorização confirma a verdade do Cliente.
Mas isso não é tudo ... Por favor, dê boas-vindas ao OpenID Connect!
O OAuth 2.0 foi desenvolvido apenas para
autorização - para fornecer acesso a dados e recursos de um aplicativo para outro.
O OpenID Connect (OIDC) é uma camada fina sobre o OAuth 2.0 que adiciona informações sobre o nome de usuário e o perfil do usuário que está conectado à conta. A organização da sessão de logon geralmente é chamada de
autenticação e as informações sobre o usuário conectado (ou seja, sobre o
Proprietário do
Recurso ) são chamadas de
identidade . Se o Servidor de Autorização suportar OIDC, às vezes é chamado de
provedor de identidade, pois fornece ao
Cliente informações sobre o
Proprietário do
Recurso .
O OpenID Connect permite implementar cenários em que um único login pode ser usado em muitos aplicativos - essa abordagem também é conhecida como SSO (logon único). Por exemplo, um aplicativo pode oferecer suporte à integração de SSO com redes sociais como Facebook ou Twitter, permitindo que os usuários usem uma conta que já possuem e que preferem usar.
O fluxo do OpenID Connect tem a mesma aparência do OAuth. A única diferença é que, na solicitação inicial, o escopo específico usado é
openid , e o
Cliente eventualmente recebe o
Token de Acesso e o
Token de ID .
Assim como no fluxo OAuth, o
Token de Acesso no OpenID Connect é um valor não compreendido pelo
Cliente . Do ponto de vista do
cliente , o
token de acesso representa uma certa cadeia de caracteres que é transmitida juntamente com cada solicitação ao
servidor de recursos , que determina se o token é válido.
O Token de ID é completamente diferente.
O Token de ID é um JWT
O Token de ID é uma cadeia de caracteres especialmente formatada, conhecida como JSON Web Token ou JWT
(às vezes, os tokens JWT são pronunciados "jots") . O JWT pode parecer uma bobagem incompreensível para pessoas de fora, mas o
Cliente pode extrair várias informações do JWT, como ID, nome de usuário, hora de login da conta, data de validade do
Token de ID e tentativas de intervir no JWT. Os dados dentro do
ID do
token são chamados de
reivindicação .
No caso do OIDC, também existe uma maneira padrão em que o
Cliente pode solicitar informações adicionais de
identidade ao
Servidor de Autorização , por exemplo, um endereço de email usando o
Token de Acesso .
Saiba mais sobre o OAuth e o OIDC.
Analisamos brevemente como o OAuth e o OIDC funcionam. Pronto para ir mais fundo? Aqui estão recursos adicionais para ajudar você a saber mais sobre o OAuth 2.0 e o OpenID Connect:
Como sempre, sinta-se à vontade para comentar. Para acompanhar as nossas mais recentes inovações, inscreva-se no Okta para
Twitter e no
YouTube para desenvolvedores!
PS do tradutor
Leia também em nosso blog: