Stands for JSON web tokens, which is a popular type of token used for Token Auth.

Is mostly stored in client, e. g. in memory or local storage. However, the most recommended approach is to store the JWT as a cookie.

User logs in with credentials
Server verifies credentials and creates JWT
Server sends JWT to client
Client includes JWT in Authorization header. This is often done automatically for further requests.
Server verifies JWT signature on each request. Based on the unique token, the server knows who the user is. The token usually contains the user id, so the server gets all the information from the token.

Pros and cons of JWT auth

Pros:

Scales very easily: As the approach is stateless on the server, no problems with distributing the database will appear. Compared to Session Auth, the session ID is stored in the database, thus, must be kept in sync across DB instances and so on. In JWT, no such information is stored on the server
Reduces DB access. Through JWTs we can get the user account linked to the JWT, without having to access the database. In Session Auth we need to select the user to the session entry.

Cons:

As the approach is stateless on the server, there is no tracking of which users are logged in or not. Thus, user sessions can’t be “logged out” and no tracking over suspicious activity is possible in this regard. This can be a dangerous affair. As we can’t deal with “stale sessions” easily, secrets to user accounts are still in existence, but we, as provider, can’t access them. This is especially problematic when different authorization levels exist. The token of an ex-admin user will be still around.

JWT + Bearer tokens