JSON Web Tokens

5f81e2d2889d7642fd84c8b24db7ee17?s=47 DamirSvrtan
September 14, 2016

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.

5f81e2d2889d7642fd84c8b24db7ee17?s=128

DamirSvrtan

September 14, 2016
Tweet

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.

  35. None
  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

  70. None
  71. HTTP ONLY COOKIE CSRF

  72. 11 RAILS IMPLEMENTATIONS

  73. None
  74. 12 DEBUG JSON WEB TOKENS

  75. None