Introdução ao OAuth 2.0

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Esta página se aplica ao Apigee e ao Apigee híbrido .

Veja a documentação do Apigee Edge .

Página inicial do OAuth : consulte a página inicial do OAuth para uma visão geral das orientações sobre OAuth que fornecemos .

Este tópico oferece uma visão geral básica do OAuth 2.0 no Apigee.

O que é OAuth 2.0?

Existem muitos livros, blogs e sites dedicados ao OAuth 2.0. Recomendamos fortemente que você comece revisando a especificação IETF OAuth 2.0 . Aqui está a definição de OAuth 2.0 da própria especificação IETF OAuth 2.0:

"A estrutura de autorização do OAuth 2.0 permite que um aplicativo de terceiros obtenha acesso limitado a um serviço HTTP, seja em nome de um proprietário de recurso, orquestrando uma interação de aprovação entre o proprietário do recurso e o serviço HTTP, ou permitindo que o aplicativo de terceiros obtenha acesso em seu próprio nome."

A principal coisa que você precisa saber é que o OAuth 2.0 fornece uma maneira para que os aplicativos obtenham acesso limitado aos recursos protegidos de um usuário (pense em uma conta bancária ou qualquer outra informação confidencial que um usuário queira acessar de um aplicativo) sem a necessidade de o usuário divulgar suas credenciais de login para o aplicativo.

O fluxo do OAuth 2.0

Este é o fluxo geral da estrutura de segurança do OAuth 2.0. Discutiremos esse fluxo com mais detalhes neste tópico, começando com um diagrama que ilustra bastante o funcionamento do OAuth 2.0. Se você não estiver familiarizado com os termos usados ​​neste diagrama, leia esta seção para uma breve introdução.

Termos que você deve conhecer

• Cliente: Também chamado de aplicativo . Pode ser um aplicativo executado em um dispositivo móvel ou um aplicativo web tradicional. O aplicativo faz solicitações ao servidor de recursos para ativos protegidos em nome do proprietário do recurso. O proprietário do recurso deve dar permissão ao aplicativo para acessar os recursos protegidos.
• Proprietário do recurso: também chamado de usuário final . Geralmente, é a pessoa (ou outra entidade) capaz de conceder acesso a um recurso protegido. Por exemplo, se um aplicativo precisa usar dados de uma de suas redes sociais, você é o proprietário do recurso — a única pessoa que pode conceder acesso aos seus dados ao aplicativo.
• Servidor de recursos: Pense no servidor de recursos como um serviço como Facebook, Google ou Twitter; ou um serviço de RH na sua intranet; ou um serviço de parceiro na sua extranet B2B. A Apigee é um servidor de recursos sempre que a validação do token OAuth é necessária para processar solicitações de API. O servidor de recursos precisa de algum tipo de autorização antes de fornecer recursos protegidos ao aplicativo.
• Servidor de autorização: O servidor de autorização é implementado em conformidade com a especificação OAuth 2.0 e é responsável por validar as concessões de autorização e emitir os tokens de acesso que concedem ao aplicativo acesso aos dados do usuário no servidor de recursos. Você pode configurar endpoints de token na Apigee, e nesse caso a Apigee assume a função de servidor de autorização.
• Concessão de autorização: concede ao aplicativo permissão para recuperar um token de acesso em nome do usuário final. O OAuth 2.0 define quatro "tipos de concessão" específicos. Consulte Quais são os tipos de concessão do OAuth 2.0 .
• Token de acesso: uma longa sequência de caracteres que serve como credencial para acessar recursos protegidos. Veja O que é um token de acesso?.
• Recurso protegido: dados de propriedade do proprietário do recurso. Por exemplo, a lista de contatos do usuário, informações da conta ou outros dados confidenciais.

Onde a Apigee se encaixa

Você pode proteger qualquer API com proxy através da Apigee com o OAuth 2.0. A Apigee inclui uma implementação de servidor de autorização e, como tal, pode gerar e validar tokens de acesso. Os desenvolvedores começam registrando seus aplicativos na Apigee. Os aplicativos registrados podem solicitar tokens de acesso por meio de qualquer uma das quatro interações de tipo de concessão .

A Apigee fornece uma política OAuthV2 multifacetada que implementa os detalhes de cada tipo de concessão, facilitando a configuração do OAuth na Apigee. Por exemplo, você pode configurar uma política que recebe uma solicitação de token de acesso, avalia todas as credenciais necessárias e retorna um token de acesso se as credenciais forem válidas.

Observe que todos os servidores de recursos que seu proxy de API seguro chama devem estar atrás de um firewall (ou seja, os recursos não devem ser acessíveis por nenhum meio além do proxy de API ou outra API bem protegida).

Quais são os tipos de concessão do OAuth 2.0?

Pense nos tipos de concessão como diferentes caminhos ou interações que um aplicativo pode seguir para obter um token de acesso. Cada tipo de concessão aborda um ou mais casos de uso, e você precisará selecionar quais tipos de concessão usar com base em suas próprias necessidades. Em geral, cada tipo de concessão tem vantagens e desvantagens, e você precisará ponderar as compensações com base nos seus casos de uso de negócios. Uma consideração importante é a confiabilidade dos aplicativos que acessarão seus dados. Geralmente, aplicativos de terceiros são menos confiáveis ​​do que aplicativos desenvolvidos e usados ​​dentro de uma empresa.

A Apigee oferece suporte aos quatro principais tipos de concessão do OAuth 2.0:

• Código de autorização — Considerado o tipo de concessão mais seguro. Antes que o servidor de autorização emita um token de acesso, o aplicativo precisa primeiro receber um código de autorização do servidor de recursos. Você já viu esse fluxo sempre que seu aplicativo abre um navegador na página de login do servidor de recursos e o convida a fazer login na sua conta real (por exemplo, Facebook ou Twitter).

Se você efetuar login com sucesso, o aplicativo receberá um código de autorização que poderá ser usado para negociar um token de acesso com o servidor de autorização. Normalmente, esse tipo de concessão é usado quando o aplicativo reside em um servidor e não no cliente. Esse tipo de concessão é considerado altamente seguro porque o aplicativo cliente nunca manipula ou vê o nome de usuário ou a senha do usuário para o servidor de recursos (ou seja, por exemplo, o aplicativo nunca vê ou manipula suas credenciais do Twitter). Esse tipo de fluxo de concessão também é chamado de OAuth de três pernas .

• Implícito — Considerado uma versão simplificada do código de autorização. Normalmente, esse tipo de concessão é usado quando o aplicativo reside no cliente. Por exemplo, o código do aplicativo é implementado em um navegador usando JavaScript ou outra linguagem de script (em vez de residir e ser executado em um servidor web separado). Nesse fluxo de concessão, o servidor de autorização retorna um token de acesso diretamente quando o usuário é autenticado, em vez de emitir um código de autorização primeiro. Concessões implícitas podem melhorar a capacidade de resposta do aplicativo em alguns casos, mas essa vantagem precisa ser ponderada em relação a possíveis implicações de segurança, conforme descrito na especificação IETF.
• Credenciais de senha do proprietário do recurso — Neste fluxo, o cliente recebe um token de acesso quando o nome de usuário/senha do usuário são validados pelo servidor de autorização. Este fluxo é recomendado para aplicações altamente confiáveis. Uma vantagem deste fluxo em relação, por exemplo, à autenticação básica, é que o usuário apresenta seu nome de usuário/senha apenas uma vez. A partir daí, o token de acesso é usado.
• Credenciais do cliente — Considere usá-las em situações em que o aplicativo cliente atua em seu próprio nome. Ou seja, o cliente também é o proprietário do recurso. Esse tipo de concessão normalmente é usado quando o aplicativo precisa acessar um serviço de armazenamento de dados de back-end, por exemplo. O aplicativo precisa usar o serviço para realizar seu trabalho, e o serviço é, de outra forma, opaco para o usuário final. Com esse tipo de concessão, um aplicativo pode receber um token de acesso apresentando seu ID do cliente e suas chaves secretas do cliente ao servidor de autorização. Nenhuma etapa adicional é necessária. fornece uma solução de credenciais de cliente pronta para uso, fácil de implementar para qualquer proxy de API.

O que é um token de acesso?

Um token de acesso é uma longa sequência de caracteres que serve como credencial para acessar recursos protegidos. Tokens de recursos (também chamados de tokens de portador) são passados ​​em cabeçalhos de autorização, como este:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

O servidor de recursos entende que o token de acesso representa credenciais como nome de usuário e senha. Além disso, os tokens de acesso podem ser emitidos com restrições, de modo que, por exemplo, o aplicativo possa ler, mas não gravar ou excluir dados no servidor de recursos. Observe que um token de acesso pode ser revogado se, por exemplo, o aplicativo for comprometido. Nesse caso, você precisará obter um novo token de acesso para continuar usando o aplicativo; no entanto, não será necessário alterar seu nome de usuário ou senha no servidor de recursos protegido (por exemplo, Facebook ou Twitter).

Os tokens de acesso geralmente têm uma data de expiração (por motivos de segurança). Alguns tipos de concessão permitem que o servidor de autorização emita um token de atualização, que permite ao aplicativo buscar um novo token de acesso quando o antigo expirar. Para mais detalhes sobre tokens de acesso e atualização, consulte a especificação IETF OAuth 2.0.

Acesso limitado por meio de escopos

Por meio do mecanismo de escopos, o OAuth 2.0 pode conceder a um aplicativo acesso limitado a recursos protegidos. Por exemplo, um aplicativo pode ter acesso apenas a recursos específicos, pode atualizar recursos ou pode receber apenas acesso somente leitura. Nos chamados fluxos OAuth de três etapas , o usuário normalmente especifica o nível de acesso por meio de uma página de consentimento (por exemplo, uma página da web onde o usuário seleciona o escopo com uma caixa de seleção ou outro mecanismo).

Registrando um aplicativo

Todos os clientes (aplicativos) devem se registrar no servidor de autorização OAuth 2.0 do qual pretendem solicitar tokens de acesso. Ao registrar um aplicativo, você recebe de volta um conjunto de chaves. Uma é uma chave pública chamada identificador do cliente e a outra é uma chave secreta chamada segredo do cliente. Sem essas chaves, um aplicativo não pode emitir solicitações de códigos de autorização ou tokens de acesso ao servidor de autorização. Observe que, embora a especificação IETF OAuth chame essas chaves de ID do cliente e segredo do cliente, a interface do usuário da Apigee as chama de ID do consumidor e segredo do consumidor. Elas são equivalentes.

Resumo dos casos de uso do OAuth 2.0

O tipo de fluxo de concessão do OAuth 2.0 que você escolher implementar dependerá do seu caso de uso específico, pois alguns tipos de concessão são mais seguros do que outros. A escolha dos tipos de concessão depende da confiabilidade do aplicativo cliente e requer uma análise muito cuidadosa, conforme descrito na tabela a seguir:

OAuth 2.0 vs. segurança de chave de API

A validação da chave de API exige que um aplicativo envie uma chave para a Apigee. A chave deve ser uma chave de consumidor válida de um aplicativo de desenvolvedor da Apigee associado ao proxy da API. Se, por algum motivo, você precisar revogar a permissão para um aplicativo cliente fazer chamadas para um proxy, será necessário revogar essa chave de consumidor. Os aplicativos clientes que usarem essa chave também não poderão acessar o proxy da API. Por outro lado, um token OAuth pode ser revogado a qualquer momento sem revogar as chaves do aplicativo. O aplicativo pode simplesmente solicitar um novo token em nome do usuário e, se um token for concedido, o aplicativo poderá continuar usando o proxy da API.

Outra diferença entre uma chave de API e um token é que um token pode incluir atributos de metadados que você pode recuperar e usar posteriormente. Por exemplo, você pode armazenar o ID do usuário que faz a chamada de API e usá-lo para personalizar chamadas para o serviço de destino do backend.

Para obter detalhes sobre a validação de chaves de API, consulte Chaves de API . Para obter informações sobre o uso de atributos personalizados com tokens OAuth, consulte Personalização de tokens e códigos de autorização .

Impacto da expiração do token e dos tempos de limpeza no armazenamento em disco

Ao gerar um novo token OAuth com a política OAuthV2, você pode definir um tempo de expiração para o token com o atributo ExpiresIn . Por padrão, os tokens são removidos do armazenamento três dias após a expiração. Se você definir um tempo de expiração longo, como 48 horas, poderá observar um aumento inesperado no uso de espaço em disco do Cassandra. Para evitar o uso excessivo de espaço em disco, você pode definir um tempo de expiração menor (recomenda-se uma hora) e/ou definir uma configuração que altere o atraso pós-expiração de três dias para um período menor.

Os clientes híbridos da Apigee podem alterar o tempo de limpeza padrão definindo a seguinte configuração no arquivo de substituições:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "SECONDS"

Onde SECONDS é o número de segundos que a Apigee aguardará para limpar os tokens após sua expiração. Certifique-se de incluir esta estrofe exatamente como está escrita, com aspas.

Por exemplo, para definir o tempo de limpeza para uma hora após a expiração:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "3600"

Recursos recomendados

Leitura

Consulte Saiba mais sobre o OAuth 2.0 .