O documento apresenta uma introdução ao protocolo OAuth2 para segurança em APIs RESTful, descrevendo seus principais conceitos como tokens, grant types e fluxos. Também discute implementações Java como Spring Security OAuth, Jersey e Apache Oltu, mostrando como OAuth2 pode fornecer autenticação e autorização sem compartilhamento de senhas.
6. Quais são os requisitos de segurança?
• Como identificar as permissões que serão manipuladas?
• Como a informação será codificada e decodificada?
• Quais dados serão necessários para restrição de acesso?
• Quem será responsável por armazenar e fornecer os
dados de segurança?
• Como identificar se a requisição não foi modificada?
“Stop bad guys from accessing your resources"
7. Segurança em APIs
• Estratégias para proteger os serviços
• Basic Auth (HTTP Basic)
• Network Security
• Certificate Based
• Arquitetura RESTful não define procedimentos de
segurança
• HTTP methods: GET, POST, PUT, DELETE
• API’s REST são tão vulneráveis quanto aplicações web
tradicionais
• SQL Injection, replay attacks, cross-site scripting, etc
8. HTTP Basic Auth
• Qual o problema com isto?
• Nada, mas…
• Em qual lugar você busca as credenciais?
• Ok para sistemas onde todos os participantes podem
compartilhar dados confidenciais de um modo seguro
• Apenas suporta informações de "usuário / senha”
• Apenas trabalha com autenticação
• Sem distinção entre usuários e máquinas
$ curl “https://$username:$password@myhost/resource"
9. Network Security
• Qual o problema com isto?
• Nada, mas…
• Chato para "debugar" e um pouco difícil de manter
• Configuração fica fora do escopo de desenvolvedores
• Não existe o conceito de identidade e autenticação
"Security architecture based on top of web server"
10. Certificate Based
• Qual o problema com isto?
• Nada, mas…
• Não existe o conceito de identidade, apenas caso o
browser tenha os certificados instalados
• Obriga keystores e certificados nas aplicações e nos
serviços
• Não existe uma distinção muito clara quanto a usuários
e máquinas
$ curl -k -cert file.pem:password https://myhost:443/resource
11. Porque OAuth
• Protocolo baseado em uma especificação de padrão
aberto definido pelo IETF
• Habilita as aplicações acessarem e compartilharem
serviços sem necessidade de compartilhar credenciais
• Evita problemas com "passwords"
• Essencial para mecanismo via delegação de acesso
• Aplicações terceiras
• Para serviços específicos
• Por um tempo limitado
• Pode trabalhar com revogação seletiva
13. OAuth Timeline
• OAuth 1.0
• Especificação core publicada em dezembro/2007
• OAuth 1.0a
• Especificação revisada publicada em junho/2009
• Relacionado a correções de vulnerabilidades de segurança
• OAuth 2.0
• Especificação publicada em outubro/2012
• Ser mais seguro, simples e padronizado
• RFCs adicionais ainda continuam sendo trabalhadas
14. OAuth 2.0
• Sem username ou passwords (apenas tokens)
• Protocol para autorização – não autenticação
• Utilizada modelo de delegação
• Evita o password sharing anti-pattern
• Estabelece confiança entre recurso, servidor de identidade e o
cliente da aplicação
• Objetivo principal é simplicidade
• Fortemente integrado com TLS/SSL
• Não é compatível com OAuth1
• Facilidades para revogação
15. OAuth 2.0 Tokens
• Tipos
• Bearer
• Large random token
• Necessita de SSL para proteção em transito
• Servidor necessita gerar e armazenar este hash
• Mac
• Utilizado para evitar repetição
• Não requer a utilização de SSL
• Apenas suportado no OAuth 1.0
• Access Token
• Short-lived token
• Refresh Token
• Long-lived token
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":“bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}
18. Papéis Envolvidos
• Resource Server
• Proteção dos serviços
• Authorization Server
• Emissão de tokens de acesso para os clientes
• Client Application
• Solicita os serviços protegidos em nome do proprietário
• Resource Owner
• Concede o acesso a um serviço protegido
19. OAuth 2.0 Grant Types
• Authorization Code (web apps)
• Confidencialidade aos clientes
• Utiliza um código de autorização emitido pelo servidor
• Implicit (browser-based and mobile apps)
• Script heavy web apps
• Usuário final pode ver o access token gerado
• Resource Owner Password Credentials (user / password)
• Utilizado em casos aonde o usuário confia no cliente
• Expõe as credenciais do usuário para o cliente
• Client Credentials (application)
• Clientes recebem um token (secret) para acesso
• Ideal para acesso entre aplicações
23. OAuth 2.0 Prós & Contras
• Prós
• Ótima integração para acesso de aplicações à
serviços oferecidos por web sites
• Acesso permitido para um escopo limitado ou por
tempo (duração)
• Sem necessidade de compartilhamento de
passwords com aplicações terceiras
• Contras
• Implementação pode ser um pouco complexa
• Problemas de interoperabilidade
• Algumas más implementações podem expor falhas
de segurança
24. OAuth 2.0 Java Implementations
• Algumas implementações Java disponíveis
• Jersey
• Apache Oltu
• Spring Security OAuth2
• Outras: CXF, Google OAuth2 API, etc
• Não suportado ainda como um padrão Java EE
25. Jersey
• Open source RESTful Web services framework
• Implementação de referência para JAX-RS
• Integrado com as anotações de segurança Java EE
• @RolesAllowed
• @PermitAll
• @DenyAll
• Suporta funcionalidades para filtro de conteúdo
• @EntityFiltering
• Apenas suporta OAuth2 como cliente :/
26. Apache Oltu
• Implementação do protocolo OAuth da Apache
• Também oferece outras implementações para padrões de
segurança
• JSON Web Token (JWT)
• JSON Web Signature (JWS)
• OpenID Connect
• Suporta todos os requisitos definidos pelo OAuth2
• Authorization Server
• Resource Server
• Client
• Fornece implementação de clientes OAuth2 para
• Facebook, Foursquare, Github, Google, etc
• Ainda continua sendo melhorado…
27. Spring Security OAuth
• Oferece implementação para OAuth (1a) e OAuth2
• Implementa os 4 tipos de authorization grants
• Suporta todos os requisitos definidos pelo OAuth2
• Authorization Server
• Resources Server
• Client
• Ótima integração com JAX-RS e Spring MVC
• Configuração utilizando anotações
• Integração com todo o eco-sistema Spring
28. Spring Authorization Server
• @EnableAuthorizationServer
• Anotação utilizada para configurar OAuth2 authorization server
• Existe também disponível em XML <authorization-server/>
• ClientDetailsServiceConfigurer
• Define os detalhes do cliente do serviço
• Implementação in-memory ou via JDBC
• AuthorizationServerTokenServices
• Operações para gerenciar OAuth2 tokens
• Tokens in-memory, JDBC ou JSON Web Token (JWT)
• AuthorizationServerEndpointConfigurer
• Fornece os grant types suportado pelo servidor
• Todos os grant types são suportados exceto via password
29. Spring Resource Server
• Pode ser a mesma instância do Authorization Server
• Ou então instalado como uma aplicação separada
• Fornece um filtro de autenticação para aplicações web
• @EnableResourceServer
• Anotação utilizada para configurar OAuth2 resource server
• Existe também disponível em XML <resource-server/>
• Suporta controle de acesso via expressions
• #oauth2.clientHasRole
• #oauth2.clientHasAnyRole
• #oauth2.denyClient
30. Spring OAuth2 Client
• Cria um filtro para armazenar o contexto do request
• Gerencia o redirecionamento de/para o servidor de
autenticação OAuth2
• @EnableOAuth2Client
• Anotação utilizada para configurar o OAuth2 client
• Existe também disponível em XML <client/>
• OAuth2RestTemplate
• Wrapper client object para acessar os serviços
31. Demo
• OAuth 2.0 Use Case
• Aplicação compartilhando serviços para diferentes clientes
• http://github.com/rcandidosilva/rest-oauth2-sample
32. Conclusões…
• Segurança é importante, mas não deve ser intrusiva
• OAuth 2.0 é um padrão que possui muitas funcionalidades
• Spring Security oferece uma boa infra-estrutura para
configuração e segurança de aplicações Java
• Spring Security OAuth oferece uma implementação
completa para o protocolo OAuth2