This is my first public speech about way to secure your API. Interective presentation you could find here - https://sergeypodgornyy.github.io/oauth-webbylab-presentation/ Security is something you want to get right. If you need to secure an API right now, I imagine you are worrying about how, exactly, to do it. It is to my surprise that JSON Web Tokens is a topic not often talked about, and I think it deserves to be in the spotlight today. We will see how easy it is to integrate it in an API authentication mechanism. If you want simple stateless HTTP authentication to an API, then JWT is just fine and relatively quick to implement. But JWT is a simple authentication protocol, OAuth is an authentication framework, that enables a third-party application to obtain limited access to an HTTP service. OAuth is a simple way to publish and interact with protected data. It's also a safer and more secure way for people to give you access.

1. OAuth and why you should
use it?
Presented to you by Sergey Podgornyy
1

2. About me
Sergey Podgornyy
Sergey Podgornyy
Full-Stack Web Developer
2

3. Agenda
1. Authentication
2. Introduction to OAuth 2.0
3. OAuth roles
4. OAuth protocol flow
5. Grant types
6. Achieving statelessness with JWT
7. Stored token vs JWT vs OAuth
8. DEMO - Token Authentication With OAuth & JWT
9. OAuth/JWT Cookbook
3

4. Authentication
Authentication
verify the identity of the user given
the credentials received
Authorization
Authorization
determine if the user should be
granted access to a particular
resource
4

5. Are our applications secure?
5

6. However,time went
6

7. Introduction to OAuth 2.0
An open protocol to allow secure authentication in a
simple and standard method from web, mobile and a
desktop applications
7

8. Resource owner
the person or the application that holds the data to be shared
Resource server
the application that holds the protected resource
Authorization server
the application that verifies the identity of the users
Client
the application that makes request to RS on behalf of the RO
OAuth 2.0: roles
8

9. OAuth 2.0: protocol flow
I want to get the
Death Star plans
9

10. OAuth 2.0: protocol flow
Hey, backend, could you please give
me a Death Star plans?
10

11. OAuth 2.0: protocol flow
Sorry mate, this is a protected resource. You will
need to present me an access token
11

12. OAuth 2.0: protocol flow
Hi, can I get an access token please?
Backend is asking
12

13. OAuth 2.0: protocol flow
Sure thing sir! I just need to ask a few
details to the user first
13

14. OAuth 2.0: protocol flow
Hi, could you please provide me your
credentials? I need to verify your identity
14

15. OAuth 2.0: protocol flow
That's no problem at all. I am vader@gmail.com
and my password is deathToJedi
15

16. OAuth 2.0: protocol flow
The user is who claims to be. Here is your
access token:
qfE2KhvKggluHqe7IpTBqZ4qziTQQbKa
16

17. OAuth 2.0: protocol flow
Hey, backend, this is my token:
qfE2KhvKggluHqe7IpTBqZ4qziTQQbKa
17

18. OAuth 2.0: protocol flow
Hi, I've been given qfE2KhvKggluHqe7IpTBqZ4qziTQQbKa .
Could you please tell me who it belongs to?
18

19. OAuth 2.0: protocol flow
Of course. That token is still valid and it belongs to
vader@gmail.com
19

20. OAuth 2.0: protocol flow
Everything is allright. This is the
Death Star plans. Enjoy!
20

21. OAuth 2.0: protocol flow
Here you are the Death Star plans! Thank you for your
bussiness and have a good day!
21

22. OAuth 2.0: protocol flow
OAuth 2.0 is a delegation protocol, as this guy
has no idea about the credentials of this guy
22

23. OAuth 2.0: grant types
1. Authorization code: for web server applications
2. Implicit: for JS front-end and mobile apps
3. Resource owner password credentials: for trusted clients
4. Client credentials: for service authentication
23

24. Authorization code grant
Involves the user granting the client an authorization code, which can be
exchanged for an Access Token
24

25. Implicit grant
25

26. Password credentials grant
26

27. Client credentials grant
This grant is suitable for machine-to-machine authentication where a specific
user’s permission to access data is not required
27

28. Responce example
{
"access_token": "RsT5OjbzRn430zqMLgV3Ia",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "e1qoXg7Ik2RRua48lXIV"
}
Except Implicit grant, where authorization server returns only an access token
01.
02.
03.
04.
05.
06.
“
28

29. Which OAuth 2.0 grant should I use?
Start
Client Credentials
Grant
Authorization
Code Grant
Implicit Grant
Password Grant
Access token
owner?
Client type?
First party or
third party client?
First party or
third party client?
Machine
User
User-agent-based
app
First party
First party
Third party
Third party
Web app
Native app
29

30. Tips for a front-end application
• Use the implicit grant
• Use HTML5's localStorage for access and refresh
tokens
30

31. RsT5OjbzRn430zqMLgV3Ia
Accessing the protected resource
Once the client has an access token, it can request a protected resource
GET /death-star/plans HTTP/1.1
Host: api.example.org
Authorization: Bearer
31

32. More grants???
Token expiration and Refresh
• If the Authorization server issues expiring tokens, they can be paired with
refresh tokens
• When the access token has expired, the refresh token can be used to get a
new access token
32

33. Stateful vs Stateless
• Authorization Servers are often stateful services
• They stored issued access token for future checking
• How can we achieve statelessness?
• Using JWT tokens as access tokens
33

34. RsT5OjbzRn430zqMLg
JWT and when it can be useful?
JWT (JSON Web Token) is a secure way to encapsulate arbitrary data that can be
sent over unsecure URL's
POST /transfer HTTP/1.1
from=acc1&to=acc2&amount=1000
vs
POST /transfer HTTP/1.1 {
"from": "acc1",
"to": "acc2",
"amount": 1000
}
“
01.
02.
03.
04.
05.
34

35. How does a JWT look like?
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJleHAiOjE0MTY0NzE5MzQsInVzZXJfbmFtZSI6InVzZXIiLCJzY29
wZSI6WyJyZWFkIiwid3JpdGUiXSwiYXV0aG9yaXRpZXMiOlsiUk9MRV
9BRE1JTiIsIlJPTEVfVVNFUiJdLCJqdGkiOiI5YmM5MmE0NC0wYjFhL
TRjNWUtYmU3MC1kYTUyMDc1YjlhODQiLCJjbGllbnRfaWQiOiJteS1j
bGllbnQtd2l0aC1zZWNyZXQifQ.
AZCTD_fiCcnrQR5X7rJBQ5rO-2Qedc5_3qJJf-ZCvVY
Header Claims Signature
35

36. JWT Header
{
"alg": "HS256",
"typ": "JWT"
}
01.
02.
03.
04.
36

37. JWT Claims
{
"exp": 1416471934,
"user_name": "user",
"scope": [
"read",
"write"
],
"authorities": [
"ROLE_ADMIN",
"ROLE_USER"
],
"jti": "9bc92a44-0b1a-4c5e-be70-da52075b9a84",
"client_id": "my-client-with-secret"
}
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
37

38. JWT Signature
HMACSHA256(
base64(header) + "." + base64(payload),
"secret"
)
38

39. Sample access token response
{
"access_token": "eyJhbGciOiJIUzI1NiJ9.
eyJleHAiOjE0MTY0NzEwNTUsInVzZXJfbmFtZSI6InVzZXIiLCJzY29wZS
I6WyJyZWFkIiwid3JpdGUiXSwiYXV0aG9yaXRpZXMiOlsiUk9MRV9BRE1J
TiIsIlJPTEVfVVNFUiJdLCJqdGkiOiIzZGJjODE4Yi0wMjAyLTRiYzItYT
djZi1mMmZlNjY4MjAyMmEiLCJjbGllbnRfaWQiOiJteS1jbGllbnQtd2l0
aC1zZWNyZXQifQ.
Wao_6hLnOeMHS4HEel1UGWt1g86ad9N0qCexr1IL7IM",
"token_type": "bearer",
"expires_in": 43199,
"scope": "read write",
"jti": "3dbc818b-0202-4bc2-a7cf-f2fe6682022a"
}
01.
02.
03.
04.
05.
06.
07.
39

40. Achieving statelessness
• Instead of storing access token / principal relationship in a stateful way, do
it on a JWT
• Access tokens with the JWT-encoded principal can be securely stored on the
client's browser
• That way you are achieving one of the basic principal of RE S T :
State Transfer
40

41. So why I should use
OAuth?
41

42. Session IDs / Cookies
Pros
• Easy to code both the client and server
• Easy to destroy a session when someone logs out
Cons
• The server side periodically needs to delete expired sessions where the
client didn't logout
• Every HTTP request requires a lookup to the data store
• Storage requirements grow as more users have active sessions
• Sometimes you need to have multiple server, and session data needs to be
accessible by all of them
42

43. JSON Web Tokens (JWT)
Pros
• The server side storage issues are gone
• The client side code is easy
Cons
• The JWT size could be larger than a session ID. It could affect network performance
• The data stored in the JWT is readable by the client
• The server side needs code to generate, validate, and read JWTs
• Anyone who gets a copy of the signing key can create JWTs. You might not know when this
happens
• There was (is?) a bug in some libraries that accepted any JWT signed with the "none" algorithm
• In order to revoke a JWT before it expires you need to use a revocation list. This gets you back to
the server side storage issues you were trying to avoid
43

44. OAuth
Pros
• No code for users to signup or reset their password
• No code to send an email with a validation link
• Users do not need to learn/write-down another username and password
Cons
• If third party service goes down or they discontinue it then you need to figure something else out
how do you migrate the user's account data if their identity changes from "foo@a.com" to "bar@b.com"?
• Usually you have to write code for each provider
• You or your users might have privacy concerns on your system. The providers know which of their
users use your service
• You are trusting the provider. It is possible for a provider to issue tokens that are valid for one user
to someone else
44

45. DEMO
45

46. See more on GitHub
46

47. Cookbook
47

48. Node.js Cookbook
Passport.js
npm install passport
Supported by
48

49. PHP Cookbook
composer require league/oauth2-client
composer require league/oauth2-server
49

50. Useful links
• The OAuth 2.0 Authorization
Framework
• OAuth 2.0 Threat Model and
Security Considerations
• JSON Web Token (JWT)
• Alex Bilbie blog
• OAuthLib documentation (.py lib)
50

51. End of presentation this is!
Any question do you have?
51