Introdução

O que é o OAuth 2.0

No modelo tradicional de autenticação cliente-servidor, o cliente solicita um acesso a um recurso restrito no servidor através da autenticação usando as credenciais do usuário. Para fornecer acesso a aplicativos de terceiros, o usuário (proprietário do recurso) compartilha suas credenciais com a terceira parte. Isso cria vários problemas e limitações:

1. Aplicativos de terceiros necessitam armazenar as credenciais do usuário para uso futuro, geralmente uma senha;
2. Servidores são obrigados a suportar autenticação por senha, vulnerabilidades de segurança inerentes às senhas;
3. Aplicativos de terceiros obtêm acesso excessivo aos recursos protegidos do usuário, sem o usuário conseguir restringir a duração deste acesso ou o conjunto de recursos a serem acessados;
4. Proprietários de recursos não podem revogar o acesso a um terceiro individualmente sem revogar o acesso a todos os terceiros, e faz isso alterando suas credenciais;
5. Comprometimento de qualquer aplicativo de terceiros resulta em comprometimento da senha do usuário final e todos os dados protegidos por senha.

OAuth resolve esses problemas introduzindo uma camada de autorização e separando o papel do cliente e do usuário. No OAuth, o cliente solicita acesso a recursos controlados pelo usuário e hospedado pelo servidor, neste caso será emitido um conjunto diferente de credenciais das do usuário. Em vez de usar as credenciais do usuário para acessar recursos, o cliente obtém um token de acesso - uma string que denota escopo específico, tempo de vida e outros atributos de acesso. Tokens de acesso são emitidos para clientes de terceiros por um servidor de autorização com a aprovação do usuário. O cliente usa o token de acesso para acessar os recursos protegidos hospedados pelo servidor.

O OAuth 2.0 divide o universo de aplicações em duas categorias: confidenciais e públicas. Confidenciais são aplicações capazes de armazenar, de forma segura, suas credenciais de acesso. Ex: aplicação web hospedada em servidor web. Já as aplicações Públicas não são capazes de armazenar de forma segura suas credenciais de acesso. Ex: aplicações mobile, desktop e SPA (Single Page Application).

Um dos pontos críticos do OAuth diz respeito ao cadastramento das aplicações, mais especificamente ao comprometimento de client_secret, possibilitando que aplicações maliciosas se passem por aplicações previamente cadastradas. Assim, não é recomendado que aplicações categorizadas pelo OAuth como Públicas portem uma client_secret.

Fluxo do Oauth 2.0

Abaixo segue, em alto nível, o fluxo do OAuth 2.0 descrevendo a interação entre as partes:

1. O cliente solicita autorização do dono do certificado. O pedido de autorização pode ser feito diretamente para o proprietário do recurso, ou de preferência indiretamente via autorização tendo o servidor como intermediário;
2. O cliente recebe uma concessão de autorização (CODE), que é uma credencial representando a autorização do proprietário do recurso, expressa usando um dos quatro tipos de concessões definidos na especificação ou usando um tipo de concessão de extensão. O tipo de concessão de autorização depende do método utilizado pelo cliente para solicitar autorização e os tipos suportados pelo servidor de autorização;
3. O cliente solicita um token de acesso ao autenticar com o servidor de autorização e apresentando a concessão de autorização( CODE );
4. O servidor de autorização autentica o cliente e valida a concessão de autorização e, se for válido, emite um token de acesso;
5. O cliente utiliza esse token para realizar uma ( ou várias ) assinatura(s).