O documento apresenta os conceitos e fluxos de autorização do OAuth2, incluindo o uso de tokens de acesso para autorizar clientes a acessarem recursos de um servidor de recursos. Explica os principais fluxos de autorização como Authorization Code e Resource Owner Credentials, além de Refresh Tokens e Client Credentials. Enfatiza a importância da segurança com SSL/TLS.

1. APIs seguras com
OAuth2
Maceió Dev Meetup #2

2. Tony Messias
Desenvolvedor Web há +4 anos
Análise de Sistemas CESMAC
@tony0x01

3. Cliente acessa recursos
usando um Access Token
obtido através de um
fluxo de autorização

4. Fim :)

5. OAuth2 > OAuth1(a)

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. 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. POST /resources HTTP/1.1
Host: api.example.com
Authorization: Bearer vr5HmMkz123aksdmMibiJUusZwZCHueHue
Content-Type: application/json
{ "lorem" : "ipsum" }

9. POST /resources HTTP/1.1
Host: api.example.com
Authorization: Bearer vr5HmMkz123aksdmMibiJUusZwZCHueHue
Content-Type: application/json
{ "lorem" : "ipsum" }

10. Mas o líder do projeto
(OAuth2) deixou o projeto

11. Inseguro se não
usar SSL/TSL

12. Inseguro se não
usar SSL/TSL
correto!

14. Alguns termos:

15. Resource Owner
também conhecido
como “usuário”

16. Resource Server
a sua API

17. Client
uma aplicação usando o
resource server a mando do
resource owner

18. Client
sua aplicação {web,mobile}
que utiliza a API

19. Authorization Server
Uma aplicação que fornece
os Access Tokens aos clients

20. Fluxos de Autorização

21. Authorization Code
o mais comum, com toda a
“dança” de redirects

22. Bob usa
uma aplicação web

23. Bob tem recursos
nessa aplicação web

24. Bob quer usar esses
recursos em uma
aplicação de terceiros

25. <a href=”https://oauth2server.com/auth?response_type=code&
client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos”>
Login with Facebook
</a>

27. Bob é redirecionado de volta
para a aplicação com um
código
https://oauth2client.com/callback?code=AUTH_CODE_HERE

28. A aplicação, então, utiliza
esse código para solicitar um
Access Token

29. 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"
}

30. Esse fluxo não é indicado
se o client for SEU

31. Resource Owner
Credentials

32. Mas o propósito do OAuth
não é nunca utilizar
credenciais do usuário?

33. Mais ou menos…

34. O propósito, na verdade, é
você não precisar fornecer
seu username e password
para terceiros

35. Mas e quando VOCÊ que
desenvolveu o client que
consome a SUA API?

36. Não faz sentido ter um
botão “login with X” quando
o X é a sua própria aplicação

38. Alice fornece seu
usuário e senha

39. O client (aplicação web)
utiliza essas credenciais para
conseguir um Access Token

40. POST https://api.oauth2server.com/token
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID
Response:
{
“access_token”: “RsT5OjbzRn430zqMLgV3Ia”
}

41. É isso! Sem mais redirects.

42. Client Credentials
as máquinas também
precisam de autorização!

43. Paracido com o Resource
Owner Credentials, mas para
aplicações

44. Exemplo: Microserviços
POST https://api.oauth2server.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

45. Refresh Token
porque Access Token deve
ter um tempo de vida

46. Você pode fornecer, junto
com o Access Token, um
Refresh Token e um TTL

47. Adiciona mais
complexidade aos clients

48. POSTahttps://api.oauth2server.com/token?
grant_type=refresh_token&refresh_token=TOKEN
{
"access_token": “ACCESS_TOKEN”,
"expires_at": timestamp,
"refresh_token": “REFRESH_TOKEN”
}

49. Sugestões

50. Envie os Access Token
via Header

52. Cuidado com
Single Page Apps

53. fim!
agora é sério!

54. 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

55. 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