TDC 2015 - Segurança em Recursos RESTful com OAuth2

1. Segurança em Recursos
RESTful com OAuth2
Rodrigo Cândido da Silva
@rcandidosilva

2. About Me
•JUG Leader do GUJavaSC
•http://gujavasc.org
•Twitter
•@rcandidosilva
•Contatos
•http://rodrigocandido.me

3. Agenda
•Segurança em APIs
•HTTP Basic Auth
•Network Security
•Certificated Based
•OAuth 2.0
•Porque utilizar OAuth2?
•Conceitos
•Grant types
•Tokens
•Implementações
•Demo

4. Web Service API’s

5. Segurança
Closed Closed Open
Autenticação Autorização

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

12. Quem está utilizando OAuth

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",
}

16. OAuth 2.0 Flow

17. OAuth 2.0 Flow

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

20. OAuth 2.0 Grant Types
•Authorization Code / Implicit
http://server/oauth/authorize?response_type=code&client_id=client
&scope=read+write+trust
&redirect_uri=http://localhost/app
http://server/oauth/token?grant_type=authorization_code&code=SkiGJ8
&client_id=client
&client_secret=secret
&redirect_uri=http://localhost/app
{"access_token":"292e1ec1-fda9-4968-b1c3-7cc0dd99483f",
"token_type":"bearer",
"expires_in":299997,
"scope":"trust write read"}

21. OAuth 2.0 Grant Types
•Resource Owner Password Credentials
http://server/oauth/token?grant_type=password&client_id=client
&client_secret=secret
&username=admin
&password=admin
{"access_token":"292e1ec1-fda9-4968-b1c3-7cc0dd99483f",
"token_type":"bearer",
"expires_in":299997,
"scope":"trust write read"}

22. OAuth 2.0 Grant Types
•Client Credentials
http://server/oauth/token?grant_type=client_credentials
&client_id=client&client_secret=secret
{"access_token":"292e1ec1-fda9-4968-b1c3-7cc0dd99483f",
"token_type":"bearer",
"expires_in":299997,
"scope":"trust write read"}

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

33. Perguntas
?

34. Referências
•http://oauth.net/2/
•http://tools.ietf.org/html/rfc6749
•http://projects.spring.io/spring-security-oauth/
•https://github.com/spring-projects/spring-security-oauth
•http://cxf.apache.org/docs/jax-rs-oauth2.html
•https://jersey.java.net/documentation/latest/security.html#d0e10940
•https://oltu.apache.org

35. Muito obrigado!
@rcandidosilva
rodrigocandido.me