JWT

Authentication and Other Uses

JWT => Json Web Token

Pronounced: \ˈjät\ - jot

https://jwt.io/

Token looks something like:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjM0LCJjc3JmX3Rva2VuIjoiYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoiLCJpYXQiOjE0NTE5Mjg1NTIsImV4cCI6MTQ1MjAxNDk1Mn0.4-1QEESDCKC0SSKzQaoC31S32_OSr3SFqNwqQOG-ZmQ

Three sections: header, payload, cryptographic signature

{"header":{
    "typ":"JWT",
    "alg":"HS256"},
 "payload":{
    "user_id":1234,
    "csrf_token":"abcdefghijklmnopqrstuvwxyz",
    "iat":1451928552,
    "exp":1452014952},
 "signature":"4-1QEESDCKC0SSKzQaoC31S32_OSr3SFqNwqQOG-ZmQ"
}

Two basic types of authentication models: stateful and stateless.

Session/cookie authentication: stateful

Server uses the session cookie to identify a persistent record that provides the session context. If the session record is not found in the database, the requestor is not authenticated.

For high-volume sites, stateful sessions are considered a liability for scalability...

Token authentication: stateless

The token contains everything the server needs to identify the requestor. There is no equivalent to a 'sessions' table in the database.

Wait a Minute...No Session Cookie?

The JWT authentication discussion is for SPA's and API access.

Old-school server-rendered applications will likely still be using Session authentication (A2, RQI, etc.)

Not sure what to say about applications where the user can switch between SPA and server-rendered pages (A2/A3). I'm guessing you'd stick with session-based Auth.

Basic Workflow

Client

Server

Login Screen

Verify credentials

username/password

token - client session data

Any authenticated request

Action

Req Params + Auth header

Response

Logout

Invalidate token

Response

Authorization Header

Authorization: Bearer abc123.bde234.cfg345

A word on client-side "session" data

Since you can store anything you want in the JWT token payload, you might be tempted to store the client-side session data there.

Don't do it.

The server login action should return the client session data separate from the token - the token is only for authentication.

Client Storage of Token

Two Main Options: local storage, cookies

Choice Moving Forward?

Cookie

Why?

The server can invalidate the token cookie on logout. If the client keeps the token in local storage, we have to trust the client application to invalidate the token on logout.

Trust No One

Gotcha's

1. The AngularJS FileUpload plugin doesn't leverage the $httpProvider, so you have to manually handle the Authorization header.
    
2. Use of an unadorned anchor tag will ALWAYS issue a request without an Authorization header. For example:
   
   <a href="/report/123.pdf">The report PDF</>
    
3. The token expiration date/time is fixed at login time. This has nothing to do with idle timeouts, etc. At the end of 24 hours (or whatever we set) you will be logged out and have to log in again.

Implementation

Ref: https://github.com/FellowRoboticists/meanStackSPA

Ref: https://github.com/GitHubAdmin/moh/tree/ds_dqi_setup

Client-side:

1. Auth interceptor to get the token from the cookie and populate the Authorization header.
2. A directive to deal with resource anchor tags in the HTML
3. Header specification when using the Angular FileUpload plugin.

Implementation

Server-side:

1. Code to generate JWT and set cookie on authentication
2. Middleware to authenticate requests
3. Code to generate resource authorization tokens
4. Middleware to authenticate resource requests

Wins

1. No Warden
2. No Session persistence
3. No AuthenticatedSystem module
4. Cross-platform
5. Better fit for SPA's than session management