Stateless authentication w/ JSON Web Tokens

Transcript

1. Authentication with JSON Web Tokens
2. 01 API AUTHENTICATION
3. CLIENT SERVER EMAIL=JOHN@EXAMPLE.COM&PASSWORD=PASS123 AUTH_TOKEN=RAND0M$TR1N6
4. CLIENT SERVER ARTICLES?AUTH_TOKEN=RAND0M$TR1N6
5. 02 SINGLE AUTH TOKEN PER USER
6. id email password_digest 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 AUTH TOKEN APPROACH
9. NAIVE IMPLEMENTATIONS NEVER EXPIRE THEM
10. STORING IT IN PLAIN TEXT
11. ISN’T THAT THE SAME AS STORING PASSWORDS IN PLAIN TEXT?
12. NOT QUITE
13. • difficult to change • used across several services PASSWORDS
14. • easy to change • auto-generated, random, unique • not used across several services AUTH TOKENS
15. 03 SINGLE HASHED AUTH TOKEN PER USER
16. NOT STORING IT IN PLAIN TEXT
17. BROWSER SERVER EM AIL=DAM IR@ EXAM PLE.COM &PASSW ORD=PASS123 AUTH_TOKEN=RAND0M $TR1N6 EM AIL=DAM IR@ EXAM PLE.COM &PASSW ORD=PASS123 MOBILE AUTH_TOKEN=ANOTHER-RAND0M $TR1N6
18. 04 MULTIPLE HASHED AUTH TOKENS PER USER
19. user_id token_digest 1 $2a$10$5FkD.. 2 $3R$D9S21$.. 1 $23$2sBPSA.. AUTH TOKENS TABLE
20. ERASE TOKENS PERIODICALLY
21. 0Rel STORE TOKENS NOWHERE WHAT IF WE DIDN’T STORE THEM ANYWHERE?
22. LET’S DO SOMETHING SIMILAR TO RAILS SESSIONS!
23. 05 RAILS SESSION STORAGE
24. CLIENT SERVER EMAIL=JOHN@EXAMPLE.COM&PASSWORD=PASS123 SET-COOKIE: APP_SESSION=23OFSKL932RDASDAFSFJ23
25. session[:user_id] = current_user.id
26. sign(encrypt(hash))
27. CLIENT SERVER APP_SESSION=23OFSKL932RDASDAFSFJ23
28. decrypt(verify_signature(cookie))
29. User.find(session[:user_id])
30. WE COULD DO SOMETHING SIMILAR… … OR FOLLOW AN OPEN STANDARD
31. 06 JSON WEB TOKENS
32. JSON Web Tokens are an open standard that defines a compact and self-contained way to securely share information between parties as a JSON Object.
33. CLIENT SERVER EMAIL=DAMIR@EXAMPLE.COM&PASSWORD=PASS123 AUTH_TOKEN=33WE.DAS3Q.ADAS
34. TO THE API CONSUMER IT CAN LOOK RANDOM..
35. ..BUT IT’S MUCH MORE
36. IT STORES INFORMATION INSIDE OF IT.
37. DATA + SIGNATURE
38. DATA + SIGNATURE data = { "user_id": 231 } token = data + sign(data)
39. ABASASD.U93RJADSF.ASASD
40. ABASASD.U93RJADSF.ASASD HEADER.PAYLOAD.SIGNATURE
41. THE JWT HEADER
42. { "typ": "JWT", "alg": "HS256" } HEADER
43. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 BASE64 ENCODED HEADER
44. THE JWT BODY
45. { “user_id": 231, "exp": 1300819380, } BODY
46. eyJpc3MiOiJzY290Y2guaW8iLCJleHAiOjE BASE64 ENCODED BODY
47. THE JWT SIGNATURE
48. 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
49. SIGNATURE 03f329983b86f7d9a9f5fef85305880101d
50. JSON WEB TOKEN eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e yJpc3MiOiJzY290Y2guaW8iLCJleHAiOjE. 03f329983b86f7d9a9f5fef85305880101d
51. iss: The issuer of the token sub: The subject 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
52. 08 JWT <> RAILS SESSIONS
53. RAILS SESSIONS ARE ENCRYPTED JWT’S ARE SIGNED
54. RAILS SESSIONS CAN’T BE READ ON THE CLIENT SIDE JWT’S CAN BE READ ON THE CLIENT SIDE
55. SECRET INFORMATION IN JWT’S MUST BE EXPLICITLY ENCRYPTED
56. 09 STATELESS AUTH
57. { “user_id": 231 } BODY
58. FORCE LOGOUT / ACCOUNT HIJACKING
59. 10 REVOCATION
60. HOW DOES DEVISE HANDLE THIS?
61. INSERT A PART OF THE USERS PASSWORD HASH INTO THE PAYLOAD
62. SESSION['WARDEN.USER.KEY'] [[1], "$2A$11$NNJPSD1Q36CG.PSQKPBU/U"]
63. { "exp": 1300819380, “user_id": 1, “pwd_start": $2a$11$nnjPSD1q36Cg.PSqKPBU }
64. DISABLE TOKENS WITH AN IAT CLAIM OLDER THAN 6.10.2017
65. { “user_id": 231, "exp": 1300819380, "iat": 1300700011, } BODY
66. id email password min_issued_at 1 damir@gmail.com $2a$10$5FkD.. 2017-09-09 08:59:06.750087
67. JTI JSON TOKEN IDENTIFIER
68. { "exp": 1300819380, "jti": 0A212BXC12, } BODY
69. id email password jti 1 damir@gmail.com $2a$10$5FkD.. DSAY039R21S
70. LOGOUTS DON’T INVALIDATE TOKENS
71. 10 JWT ADVANTAGES
72. SAFELY SHARE DATA WITH THE CLIENT APP
73. { “user_id": 231, "admin": true, “permissions”: [‘read’, ‘write’] }
74. SELF CONTAINED TIME-BASED EXPIRATION HANDLING
75. SCALABILITY
76. MICROSERVICES INFORMATION SHARING
77. NOT REINVENTING THE WHEEL - USING AN OPEN STANDARD.
78. LANGUAGE SUPPORT
79. JWT.IO RUBY, ELIXIR, GO, PYTHON, JAVA, RUST..
80. 11 RAILS IMPLEMENTATIONS
84. CONCLUSIONS
85. SCALABILITY. SIMPLICITY. STANDARDIZATION.
86. ALWAYS IMPLEMENT A REVOCATION TECHNIQUE
87. NO SILVER BULLET.
89. Damir Svrtan Rails Team Lead @ infinum.co Organizer @ Ruby Zagreb Hit me up on twitter @DamirSvrtan