Auth Headers vs JWT vs Sessions — How to Choose the Right Auth Technique for APIs

Authenticating REST APIs calls for selecting the right one that suits your application. There are several ways:

There are two choices for Single Page Applications:

• Session Based
• Token-Based authentication

The set of questions that need to be asked are:

1. Should the sessions be invalidated before they expire? If Yes, Sessions must be preferred.
2. Should the session end based on inactivity as against ending after a fixed time? If Yes, Sessions must be preferred.
3. Should the me functionality be remembered? If Yes, Sessions must be preferred.
4. Will mobile applications to use the same APIs? If yes, prefer token-based authentication (but ensure a separate API is built for these use cases)
5. Is Your web framework protected against CSRF? Prefer token based authentication if it is a “No” or if you don’t know what CSRF is.

If token-based authentication is preferred, avoid JSON Web Tokens. JWT should be used as a short, one-time token, as against something that is reused multiple times. Alternatively, you could create a random token, store it in Redis/Memcached, and validate it on every request.

Prefer token-based authentication.

Mobile apps do not automatically maintain and send session cookies. Hence it would be far easier for a mobile app developer to set an authentication token as opposed to setting a session cookie.

Signature-based mechanisms too aren’t useful as secret keys cannot be embedded in a mobile application. Only when you have another channel, say a QR code, to pass secrets, you could use signature-based mechanisms.

A random token stored in Redis or Memcached is the most ideal approach. Ensure you use a cryptographically secure random generator in your programming.

The three choices for APIs that are called from a server-side application includes:

• Basic authentication over https
• Token-based authentication
• Signature-based authentication

1. Will the API be used only internally and only by the applications you control, are the API themselves of low value? If yes, as long as you are using HTTPS, basic authentication is acceptable.
2. Would you want the keys to be long-lived? If yes, since the keys themselves are never sent over the wire, signature-based authentication.
3. Would you want the same APIs to be used for both mobile and web apps? If yes, since signature based auth requires clients to store secrets, prefer token-based authentication.
4. Are you using OAuth? If yes, the decision is made for you. OAuth 1 uses signature-based authentication, whereas OAuth 2 uses token-based authentication.
5. Do you provide a client library to access your APIs? If yes, prefer signature based auth, because you can then write the cryptography code once and provide it to all your clients.

JWT works best for single use tokens. Ideally, a new JWT must be generated for each use. Acceptable use cases:

1. Server-to-server API calls, where the client can store a shared secret and generate a new JWT for each API call.
2. Generate links that expire shortly — such as those used for email verification
3. As a way for one system to provide a logged in user limited access to another system.

OAuth should be used, only if the below criteria are met:

1. The Consumers or the user-specific data is exposed by your API
2. Some of the user-specific data is being accessed by third-party developers that you don’t trust
3. If You want to ask your users if they want to share their data with the third party developer

If the answer is “yes” to ALL the 3 questions, you require OAuth.

Originally published on hashedin.com on June 18, 2018.