O que é OAuth?
Jinhua Luo
November 18, 2022
Criar novas contas para todos os diferentes sites sempre foi um problema. A maioria delas envolve trabalho redundante, pois todas contêm as mesmas informações do usuário, como nome e número de telefone.
“É possível permitir que um aplicativo acesse meus dados sem necessariamente fornecer minha senha?”
O OAuth é um padrão que tenta resolver esse problema fornecendo autorização centralizada.
O OAuth, que significa “Open Authorization” (Autorização Aberta), é um padrão aberto para delegação de acesso. Ele permite que você (proprietário dos recursos) compartilhe informações entre aplicativos e sites sem expor suas senhas. É amplamente utilizado, e você provavelmente usa serviços OAuth diariamente. Por exemplo, para fazer login no GeeksforGeek, você pode optar por fazer login usando sua conta do Google. Ao fazer isso, você autoriza o GeeksforGeek a acessar algumas das informações da sua conta do Google, como nome de usuário, foto de perfil, etc.
História do OAuth
O protocolo OAuth 1.0 foi publicado como RFC 5849, um Request for Comments informativo, em abril de 2010.
O protocolo OAuth 2.0 foi publicado como RFC 6749, e o Uso de Token Portador OAuth 2.0 foi publicado como RFC 6750, em outubro de 2012.
Embora tenha sido construído com base na experiência de implantação do OAuth 1.0, o OAuth 2.0 é uma reescrita completa do OAuth 1.0 do zero, compartilhando apenas objetivos gerais e experiência geral do usuário. O OAuth 2.0 não é compatível com versões anteriores do OAuth 1.0.
Como o OAuth 2.0 Funciona
No protocolo OAuth, em vez de usar o nome de usuário e senha do proprietário do recurso para acessar recursos protegidos, o cliente usa um token de acesso. O cliente obtém o token de acesso de um servidor de autorização após a aprovação do proprietário do recurso. Para que o proprietário do recurso conceda autorização ao cliente, ele deve primeiro ser autenticado no aplicativo. E como a autenticação ocorreu apenas entre o proprietário do recurso e o aplicativo, o cliente de terceiros não tem como saber qualquer informação privada do proprietário do recurso.
Podemos ver que a implementação do protocolo OAuth simplificará significativamente o processo de autenticação do cliente de terceiros. Tudo o que ele precisa fazer é obter autorização do usuário, solicitar o token de acesso, usá-lo e obter as informações do usuário (recurso protegido). Ele não exigirá que novos usuários registrem contas ou exponham suas credenciais, reduzindo assim a superfície de ataque e aumentando a segurança da rede.
Vale ressaltar que o OAuth não é autenticação. O "Auth" aqui é autorização. O usuário não faz login no aplicativo. Ele apenas autoriza o aplicativo de terceiros a obter algumas de suas informações.
Processo de Autorização do OAuth
Papéis
O OAuth define quatro papéis:
Cliente - O aplicativo que deseja acessar seus dados (proprietário do recurso) e fazer solicitações de recursos protegidos em nome do proprietário do recurso e com sua autorização.
Proprietário do recurso - Um usuário que possui os dados no servidor de recursos, deseja usar o serviço do cliente e tem uma conta no servidor de autorização. Por exemplo, eu sou o proprietário do recurso do meu perfil no Facebook e quero usar o serviço do GeeksforGeeks.
Servidor de autorização - O principal mecanismo do OAuth. Emite tokens de acesso para o cliente após autenticar com sucesso o proprietário do recurso e obter autorização.
Servidor de recursos - O servidor que armazena os dados que o cliente deseja, capaz de aceitar e responder a solicitações de recursos protegidos usando tokens de acesso.
Fluxo do Protocolo OAuth
Passo A: O aplicativo de terceiros solicita autorização do usuário
Passo B: O aplicativo de terceiros recebe uma concessão de autorização, que é uma credencial que representa a autorização do proprietário do recurso
Passo C: O aplicativo de terceiros solicita um token de acesso usando a concessão de autorização
Passo D: O servidor de autorização autentica o cliente e valida a concessão de autorização; se válida, ele emite um token de acesso para o aplicativo de terceiros
Passo E: O aplicativo de terceiros usa o token de acesso para solicitar os recursos protegidos do servidor de recursos
Passo F: O servidor de recursos valida o token de acesso e atende à solicitação se for válido
Código de Autorização e Token de Acesso
Existem quatro tipos de concessão de autorização para obter tokens de acesso dos servidores de autorização. Vamos falar apenas sobre o método Código de Autorização aqui, pois é o método mais seguro e comum.
Passo A: O aplicativo de terceiros permite que o usuário escolha um método de autorização, como GitHub, e então redireciona o usuário para o servidor de autorização com parâmetros como client_id e redirect_uri
Exemplo de solicitação:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
Passo B: O usuário faz login e autoriza
Passo C: O servidor de autorização redireciona o usuário de volta para o backend do aplicativo de terceiros de acordo com o redirect_uri, fornecendo o código de autorização
Exemplo de resposta:
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
Passo D: O aplicativo de terceiros usa o código de autorização para trocar pelo token de acesso do servidor de autorização
Exemplo de solicitação:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Passo E: O servidor de autorização valida e retorna o token de acesso
Exemplo de resposta do servidor de autorização:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
Um Exemplo Concreto
Bob deseja imprimir de forma organizada seus pedidos na Amazon usando um software chamado Rabbit.
Proprietário do recurso -> Bob
Cliente (aplicativo de terceiros) -> Software Rabbit
Servidor de autorização -> Servidor de autorização da Amazon
Servidor de recursos -> Bancos de dados da Amazon para armazenar informações de pedidos
Recursos protegidos -> Informações de pedidos de Bob na Amazon
Por que o Código de Autorização e o Token de Acesso Devem Ser Obtidos Separadamente?
O código de autorização e o token de acesso são obtidos separadamente para garantir medidas de segurança.
No protocolo OAuth2, o código de autorização é um código temporário que o cliente trocará por um token de acesso. O código é obtido do servidor de autorização, onde o usuário (proprietário do recurso) tem a chance de ver quais informações o cliente solicita e aprovar ou negar a solicitação.
Depois que o usuário faz login e autoriza com sucesso, ele é redirecionado de volta ao aplicativo com um código de autorização temporário na URL.
Esse código de autorização geralmente é válido por dez minutos e apenas uma vez. O curto período de validade reduz o risco de vazamento de informações do usuário se ele for roubado. Em contraste, o período de validade do access_token é relativamente longo, geralmente de 1 a 2 horas. Se ele vazar, pode representar um perigo maior para a segurança dos dados do usuário.
Além disso, para trocar por um token de acesso, o cliente precisará fornecer client ID e client secret, além do código de autorização. O servidor de autorização precisa desses parâmetros para autenticar o cliente e verificar se aquele que solicita o token de acesso é confiável. Se o código de autorização for infelizmente vazado, mas o hacker não tiver o client ID e o client secret, ele ainda não poderá obter o código de acesso. Mesmo que ele de alguma forma tenha o client ID e o client secret, ainda precisará competir com o servidor do cliente, porque o código de autorização é único. Esse mecanismo aumenta significativamente a dificuldade de possíveis ataques. Se pulássemos a etapa de obtenção do código de autorização e retornássemos o token de acesso diretamente, o atacante poderia usar o token de acesso para roubar informações do usuário facilmente.
OIDC (OpenID Connect)
Qual é o propósito de usar o OAuth para autorização? É obter todos os tipos de informações sobre o usuário. Por que não podemos padronizar a saída para que os aplicativos de terceiros possam usá-la diretamente?
O OIDC faz essa padronização.
Como o OIDC faz isso? Simplificando, ele retorna um id_token adicional no formato JWT contendo as informações básicas do usuário junto com o access token. Os aplicativos de terceiros podem obter informações do usuário verificando o algoritmo de assinatura e validando a assinatura no id_token com uma chave pública.
Além disso, o OIDC fornece o endpoint UserInfo. Os serviços de terceiros podem usar o token de acesso para acessar esse endpoint e obter informações adicionais sobre o usuário.
Outra característica do OIDC é o Single Sign On (SSO) e o Single Log Out (SLO). O SSO melhora a usabilidade, permitindo que o usuário tenha sessões autenticadas com diferentes clientes sem precisar fornecer credenciais todas as vezes. Desde que o usuário faça login com sucesso em um aplicativo, não há necessidade de inserir a senha novamente ao fazer login em outros aplicativos.
O SLO melhora a segurança, garantindo que nenhuma sessão ativa seja deixada de uma sessão SSO após o usuário iniciar um único logout. Os usuários só precisam fazer logout uma vez e todas as sessões serão encerradas, impedindo que sejam sequestradas ou usadas indevidamente.
Vale ressaltar que o OIDC não está padronizando um método de autenticação específico, como senhas ou reconhecimento facial. Em vez disso, ele especifica como delegar a autenticação a um provedor de autenticação centralizado, o que obtemos após a autenticação - id token, como esse token é verificado - formato JWT, e quais informações do usuário esse id token contém. Assim, os aplicativos de terceiros não precisam mais reinventar a roda.
Suporte do APISIX para OAuth/OIDC
Apache APISIX é um gateway de API de código aberto nativo da nuvem. É um Gateway de API dinâmico, em tempo real e de alto desempenho, e você pode usá-lo para lidar com o tráfego tradicional norte-sul, bem como o tráfego leste-oeste entre serviços. Ele também pode ser usado como um controlador de ingress do k8s.
Como o APISIX é um gateway de API que atua como um proxy para vários servidores de aplicativos upstream, é mais natural colocar a autorização centralizada e a autenticação no gateway de API.
O plugin OpenID Connect (OIDC) do APISIX suporta o protocolo OpenID Connect. Os usuários podem usar esse plugin para conectar o APISIX a muitos provedores de identidade (IdP), como Okta, Keycloak, Ory Hydra, Authing, etc., e implantá-lo como um gateway de autenticação centralizado. O OIDC é um superconjunto do OAuth, então esse plugin também suporta OAuth.
Diagrama de implantação:
Exemplo de Configuração: Integrar o Keycloak para Autenticação com o Apache APISIX
Configurar o Keycloak
| Parâmetro | Valor |
|---|---|
| endereço do keycloak | http://127.0.0.1:8080/ |
| Realm | myrealm |
| Tipo de Cliente | OpenID Connect |
| ID do Cliente | myclient |
| Segredo do Cliente | e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq |
| URI de Redirecionamento | http://127.0.0.1:9080/anything/callback |
| Discovery | http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration |
| URI de Logout | /anything/logout |
| Nome de Usuário | myuser |
| Senha | myrealm |
| Realm | mypassword |
Código de Exemplo
curl -XPUT 127.0.0.1:9080/apisix/admin/routes/1 -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
"uri":"/anything/*",
"plugins": {
"openid-connect": {
"client_id": "myclient",
"client_secret": "e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq",
"discovery": "http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration",
"scope": "openid profile",
"bearer_only": false,
"realm": "myrealm",
"redirect_uri": "http://127.0.0.1:9080/anything/callback",
"logout_path": "/anything/logout"
}
},
"upstream":{
"type":"roundrobin",
"nodes":{
"httpbin.org:80":1
}
}
}'
Quando você visitar http://127.0.0.1:9080/anything/test após a criação bem-sucedida da API, será direcionado para a página de login do Keycloak porque você não fez login:
Digite myuser como nome de usuário e mypassword como senha, e você será direcionado para a seguinte página.
Visite http://127.0.0.1:9080/anything/logout para fazer logout:
Resumo
Em resumo, o padrão OAuth é uma solução popular tanto para aplicativos quanto para usuários. Ele fornece conveniência e segurança, permitindo que os usuários utilizem serviços em várias plataformas sem compartilhar suas credenciais. Apache APISIX é um Gateway de API popular que suporta a integração de vários provedores de identidade (Keycloak, Ory Hydra, Okta, Auth0, etc.) para proteger suas APIs.
Leia mais sessões: