APIs seguras com OAuth2

550 visualizações

Publicada em

Uma introdução simplificada dos principais conceitos do OAuth2 para o segundo encontro do Maceió DEV Meetup!

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
550
No SlideShare
0
A partir de incorporações
0
Número de incorporações
47
Ações
Compartilhamentos
0
Downloads
15
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

APIs seguras com OAuth2

  1. 1. APIs seguras com OAuth2 Maceió Dev Meetup #2
  2. 2. Tony Messias Desenvolvedor Web há +4 anos Análise de Sistemas CESMAC @tony0x01
  3. 3. Cliente acessa recursos usando um Access Token obtido através de um fluxo de autorização
  4. 4. Fim :)
  5. 5. OAuth2 > OAuth1(a)
  6. 6. POST /resources HTTP/1.1 Host: api.example.com Authorization: OAuth oauth_consumer_key=" lWsZaXcyujT8ErqdIlbr0Sn9LaFYNlE2eVCczyvsFKnmBHiBnVrY3xo64 ByB", oauth_nonce="0Sn9LaFYN", oauth_signature=" lWsZaXcyujT8ErqdIlbr0Sn9LaFY", oauth_signature_method=" HMAC-SHA1", oauth_timestamp="1418836421", oauth_token=" 96403f692107210ef11f4a02cdbce4af", oauth_version="1.0" Content-Type: application/json { "lorem" : "ipsum" }
  7. 7. POST /resources HTTP/1.1 Host: api.example.com Authorization: OAuth oauth_consumer_key=" lWsZaXcyujT8ErqdIlbr0Sn9LaFYNlE2eVCczyvsFKnmBHiBnVrY3xo64 ByB", oauth_nonce="0Sn9LaFYN", oauth_signature=" lWsZaXcyujT8ErqdIlbr0Sn9LaFY", oauth_signature_method=" HMAC-SHA1", oauth_timestamp="1418836421", oauth_token=" 96403f692107210ef11f4a02cdbce4af", oauth_version="1.0" Content-Type: application/json { "lorem" : "ipsum" }
  8. 8. POST /resources HTTP/1.1 Host: api.example.com Authorization: Bearer vr5HmMkz123aksdmMibiJUusZwZCHueHue Content-Type: application/json { "lorem" : "ipsum" }
  9. 9. POST /resources HTTP/1.1 Host: api.example.com Authorization: Bearer vr5HmMkz123aksdmMibiJUusZwZCHueHue Content-Type: application/json { "lorem" : "ipsum" }
  10. 10. Mas o líder do projeto (OAuth2) deixou o projeto
  11. 11. Inseguro se não usar SSL/TSL
  12. 12. Inseguro se não usar SSL/TSL correto!
  13. 13. Alguns termos:
  14. 14. Resource Owner também conhecido como “usuário”
  15. 15. Resource Server a sua API
  16. 16. Client uma aplicação usando o resource server a mando do resource owner
  17. 17. Client sua aplicação {web,mobile} que utiliza a API
  18. 18. Authorization Server Uma aplicação que fornece os Access Tokens aos clients
  19. 19. Fluxos de Autorização
  20. 20. Authorization Code o mais comum, com toda a “dança” de redirects
  21. 21. Bob usa uma aplicação web
  22. 22. Bob tem recursos nessa aplicação web
  23. 23. Bob quer usar esses recursos em uma aplicação de terceiros
  24. 24. <a href=”https://oauth2server.com/auth?response_type=code& client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos”> Login with Facebook </a>
  25. 25. Bob é redirecionado de volta para a aplicação com um código https://oauth2client.com/callback?code=AUTH_CODE_HERE
  26. 26. A aplicação, então, utiliza esse código para solicitar um Access Token
  27. 27. POST https://api.oauth2server.com/token grant_type=authorization_code& code=AUTH_CODE_HERE& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID& client_secret=CLIENT_SECRET Reponse: { "access_token":"RsT5OjbzRn430zqMLgV3Ia" }
  28. 28. Esse fluxo não é indicado se o client for SEU
  29. 29. Resource Owner Credentials
  30. 30. Mas o propósito do OAuth não é nunca utilizar credenciais do usuário?
  31. 31. Mais ou menos…
  32. 32. O propósito, na verdade, é você não precisar fornecer seu username e password para terceiros
  33. 33. Mas e quando VOCÊ que desenvolveu o client que consome a SUA API?
  34. 34. Não faz sentido ter um botão “login with X” quando o X é a sua própria aplicação
  35. 35. Alice fornece seu usuário e senha
  36. 36. O client (aplicação web) utiliza essas credenciais para conseguir um Access Token
  37. 37. POST https://api.oauth2server.com/token grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID Response: { “access_token”: “RsT5OjbzRn430zqMLgV3Ia” }
  38. 38. É isso! Sem mais redirects.
  39. 39. Client Credentials as máquinas também precisam de autorização!
  40. 40. Paracido com o Resource Owner Credentials, mas para aplicações
  41. 41. Exemplo: Microserviços POST https://api.oauth2server.com/token? grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
  42. 42. Refresh Token porque Access Token deve ter um tempo de vida
  43. 43. Você pode fornecer, junto com o Access Token, um Refresh Token e um TTL
  44. 44. Adiciona mais complexidade aos clients
  45. 45. POSTahttps://api.oauth2server.com/token? grant_type=refresh_token&refresh_token=TOKEN { "access_token": “ACCESS_TOKEN”, "expires_at": timestamp, "refresh_token": “REFRESH_TOKEN” }
  46. 46. Sugestões
  47. 47. Envie os Access Token via Header
  48. 48. Cuidado com Single Page Apps
  49. 49. fim! agora é sério!
  50. 50. Referências ➔ https://speakerdeck.com/jacksonj04/oauth-101 ➔ https://leanpub.com/build-apis-you-wont-hate ➔ http://tools.ietf.org/html/rfc6749 ➔ http://alexbilbie.com/ ➔ http://oauth2.thephpleague.com/ ➔ https://github.com/reddit/reddit/wiki/OAuth2
  51. 51. Referências ➔ https://aaronparecki. com/articles/2012/07/29/1/oauth2-simplified ➔ http://bshaffer.github.io/oauth2-server-php- docs/overview/grant-types/ ➔ http://pt.slideshare.net/TiagoMarchettiDolphi/oauth2- uma-abordagem-para-segurana-de-aplicaes-e-apis- rest-devcamp-2014

×