JSON Web Tokens

A presentation about JSON Web Tokens and all the pros and cons of using them. Also a note on integrating it with Rails.

Transcript

1. JSON Web Tokens DAMIR SVRTAN
2. 01 JSON API AUTHENTICATION
3. CLIENT SERVER EMAIL=DAMIR@EXAMPLE.COM&PASSWORD=PASS123 ACCESS_TOKEN=RAND0M$TR1N6
4. CLIENT SERVER ARTICLES?ACCESS_TOKEN=RAND0M$TR1N6
5. 02 SINGLE ACCESS TOKEN PER USER
6. id email password auth_token 1 damir@gmail.com $2a$10$5FkD.. 23ZS921a USERS TABLE
7. GENERATE A RANDOM AUTH TOKEN class User before_save :generate_auth_token def generate_auth_token loop do self.auth_token = Devise.friendly_token break if User.find_by_auth_token(auth_token).nil? end end end
8. PROBLEMS WITH THE SINGLE ACCESS TOKEN APPROACH
9. STORING IT IN PLAIN TEXT
10. Is it the same as storing passwords in plain text? ALMOST.
11. Passwords • when compromised are difficult to change • reveal information about people who created them • people use them across several services
12. Authentication Tokens • auto-generated, random, unique (not shared across multiple services). • when compromised can be renewed easily with little user inconvenience
13. NAIVE IMPLEMENTATIONS NEVER EXPIRE THEM
14. 03 SINGLE HASHED ACCESS TOKEN PER USER
15. NOT STORING IT IN PLAIN TEXT
16. PROBLEMS WITH THE SINGLE HASHED ACCESS TOKEN APPROACH
17. BROWSER SERVER EM AIL=DAM IR@ EXAM PLE.COM &PASSW ORD=PASS123 ACCESS_TOKEN=RAND0M $TR1N6 EM AIL=DAM IR@ EXAM PLE.COM &PASSW ORD=PASS123 MOBILE ACCESS_TOKEN=ANOTHER-RAND0M $TR1N6
18. 04 MULTIPLE HASHED ACCESS TOKENS PER USER
19. MAINTAINING A SEPARATE TABLE OF ACCESS TOKENS
20. COMPLICATING TOO MUCH..
21. ROLLING YOUR OWN AUTHENTICATION SYSTEM
22. 01 WHO ARE WE?
23. WHY DON’T WE TRY TO DO THE SAME THING AS RAILS APPS REGULARLY DO?
24. 05 RAILS SESSION STORAGE
25. session[:user_id] = current_user.id
26. CLIENT SERVER EMAIL=DAMIR@EXAMPLE.COM&PASSWORD=PASS123 SET-COOKIE: PRODUCTIVE_SESSION=23OFSKL932RDASDAFSFJ23
27. User.find(session[:user_id])
28. STATELESS
29. WE COULD DO SOMETHING SIMILAR… …OR FOLLOW AN INDUSTRY STANDARD
30. 06 JSON WEB TOKENS
31. JSON Web Tokens are an open, industry standard method for representing claims securely between two parties.
32. CLIENT SERVER EMAIL=DAMIR@EXAMPLE.COM&PASSWORD=PASS123 ACCESS_TOKEN=33WE.DAS3Q.ADAS
33. TO THE API CONSUMER IT CAN LOOK RANDOM.. BUT IT’S MUCH MORE
34. IT STORES INFORMATION INSIDE OF IT.
36. 07 JWT STRUCTURE
37. ABASASD.U93RJADSF.ASASD
38. HEADER.PAYLOAD.SIGNATURE
39. { "typ": "JWT", "alg": "HS256" } HEADER
40. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 BASE64 ENCODED HEADER
41. { "iss": "infinum.co", "exp": 1300819380, "name": "Kolega Frend", "user_id": 231 } BODY
42. iss: The issuer of the token sub: The subject of the token aud: The audience of the token exp: This will define the expiration in NumericDate value. nbf: Defines the time before which the JWT MUST NOT be accepted for processing iat: The time the JWT was issued. Can be used to determine the age of the JWT BODY CLAIMS
43. eyJpc3MiOiJzY290Y2guaW8iLCJleHAiOjE BASE64 ENCODED BODY
44. encoded_string = Base64.encode64(header) + "." + Base64.encode64(payload); OpenSSL::HMAC.hexdigest( OpenSSL::Digest.new(‘sha256'), Rails.application.secrets.secret_key_base, encoded_string ) GENERATE A SIGNATURE
45. SIGNATURE 03f329983b86f7d9a9f5fef85305880101d
46. JSON WEB TOKEN eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJzY290Y2guaW8iLCJleHAiOjE. 03f329983b86f7d9a9f5fef85305880101d
47. THEY CARRY INFORMATION INSIDE OF THEMSELVES JUST LIKE RAILS SESSIONS DO
48. 08 JWT AND RAILS SESSION DIFFERENCES
49. RAILS SESSIONS ARE ENCRYPTED JWT’S ARE SIGNED
50. RAILS SESSIONS CAN’T BE READ ON THE CLIENT SIDE JWT’S CAN BE READ ON THE CLIENT SIDE
51. SECRET INFORMATION IN JWT’S MUST BE EXPLICITLY ENCRYPTED
52. 09 JWT ADVANTAGES
53. SAFELY SHARE DATA WITH THE CLIENT APP
54. NOT REINVENTING THE WHEEL - USING AN INDUSTRY STANDARD.
55. PERSISTENCE LAYER AGNOSTIC - SINCE YOU DON’T PERSIST IT! ACTIVERECORD/SEQUEL/MONGODB/NEO4J
56. AUTOMATIC TIME-BASED EXPIRATION HANDLING
57. NO SESSION LOOKUP
58. SINGLE-SIGN-ON ACROSS MULTIPLE APPLICATIONS WITH UUIDS
59. MACHINE-TO-MACHINE INFORMATION SHARING
60. 09 JWT DISADVANTAGES
61. NO LOGOUTS
62. HARDER TOKEN REVOCATION
63. 10 JWT REVOCATION
64. FLAG A USER AS DISABLED
65. DISABLE TOKENS WITH AN IAT CLAIM OLDER THAN 14.09.2016
66. INSERT AN USERS ENCRYPTED PASSWORD HASH INTO THE PAYLOAD
67. 10 STORING TOKENS ON THE FRONTEND
68. LOCALSTORAGE XSS
69. COOKIES XSS + CSRF
71. HTTP ONLY COOKIE CSRF
72. 11 RAILS IMPLEMENTATIONS
74. 12 DEBUG JSON WEB TOKENS