OAuth 2 & OpenID Connect
Entenda de maneira rápida seus conceitos e vocabulários.
OpenID & OAuth
Para entender as diferenças e funções dos protocolos OpenID e OAuth, precisamos frisar alguns significados.
Autorização:
O processo de autorização decide se uma pessoa, programa ou dispositivo X tem permissão para acessar determinado dado, programa de computador ou serviço Y. Leia mais
Autenticação:
A autenticação também remete à confirmação da procedência de um objeto ou pessoa, neste caso, frequentemente relacionada com a verificação da sua identidade. Leia mais
A relação dos dois:
A autenticação é o processo que verifica a identidade de uma pessoa, por sua vez, a autorização verifica se esta pessoa possui permissão para executar determinadas operações. Por este motivo, a autenticação sempre precede a autorização.
Agora para finalizar, a relação entre tudo isso e os protocolos:
O OpenID é um protocolo que lida com a autenticação, enquanto que o OAuth 2.0 é, na maioria dos casos, para autorização.
OpenID Connect(OIDC)
O OpenID Connect , para os mais íntimos OIDC, é nada mais nada menos do que uma camada de autenticação em cima do OAuth 2.0, focando na parte de autenticar usuários. Embora o OAuth 2.0 consiga fazer autorização, ele não faz ideia de quem é o usuário referido, nesse contexto essa camada OpenID Connect vai agregar os dados do usuário, consequentemente agregando autenticação.
Vocabulário:
O OAuth 2.0 possui algo que chamamos de OAuth Flow, e este possui uma série de palavras que ajudam no seu entendimento. Abaixo temos descrito parte delas.
Resource Owner: Basicamente o usuário, dono das informações.
Client: Aplicação que quer acessar dados usando o consentimento do usuário.
Authorization Server: Aplicação que “conhece” o Resource Owner.
Resource Server: Aplicação a qual o Client deseja acesso às informações. As vezes pode acontecer de o Resource Server e o Authorization Server serem os mesmos ou de o Authorization Server ser alguma aplicação a qual o Resource Server confia.
SCOPE: São as permissões granulares que o Client deseja que sejam autorizadas pelo usuário.
Exemplo do dia-a-dia
Todos nós, usuários de internet, já nos deparamos com a seguinte situação:
Além do site disponibilizar a possibilidade de criar uma conta dentro da aplicação, você pode também fazer login utilizando outras aplicações, no caso Google e Facebook.
Tanto o Google quanto o Facebook podem agir como Resource Server e Authentication Server. Suponhamos que você escolha o Google como Resource Server e assim consequentemente como Authentication Server, você cairá na imagem abaixo:
Suponhamos também que digitou seu e-mail e senha Google e clicou em próximo, você será redirecionado para a tela de autorização abaixo.
O próprio Google, com base no que a aplicação quer acessar dos seus dados, vai lhe apresentar tudo o que o Client, Pinterest, deseja acessar em um list box.
Esse list box é chamado de SCOPE granular, é nesse estágio que o usuário pode decidir a quais dados o Pinterest pode acessar dentro do Resource Server, nesse caso o Resource Server é alguma aplicação do Google que tenha os dados descritos no SCOPE.
Ao clicar em permitir você será redirecionado para a tela inicial do Pinterest.
Necessário salientar que ao longo desse processo você passou por uma autenticação com o OAuth 2.0, onde o Google como Authentication Server pede para você logar com sua conta, e uma autorização, onde você precisou permitir que o Pinterest acessasse os dados que ele precisa dentro da aplicação que ele desejava do Google.
Considerações
A maior parte das informações descritas neste artigo foram retiradas do guia feito por David Neal, sobre o OAuth 2.0 e OpenID Connect, da documentação do Google e do próprio site do OpenID Connect.
Este artigo terá uma segunda parte explicando como esses protocolos agem do debaixo dos panos e também uma terceira parte mostrando como configurar o OpenID Connect para sua aplicação.
