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: If Yes, Sessions must be preferred. Should the sessions be invalidated before they expire? If Yes, Sessions must be preferred. Should the session end based on inactivity as against ending after a fixed time? If Yes, Sessions must be preferred. Should the me functionality be remembered? If yes, prefer token-based authentication (but ensure a separate API is built for these use cases) Will mobile applications to use the same APIs? Prefer token based authentication if it is a “No” or if you don’t know what CSRF is. Is Your web framework protected against CSRF? 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 If yes, as long as you are using HTTPS, basic authentication is acceptable. Will the API be used only internally and only by the applications you control, are the API themselves of low value? If yes, since the keys themselves are never sent over the wire, signature-based authentication. Would you want the keys to be long-lived? If yes, since signature based auth requires clients to store secrets, prefer token-based authentication. Would you want the same APIs to be used for both mobile and web apps? If yes, the decision is made for you. OAuth 1 uses signature-based authentication, whereas OAuth 2 uses token-based authentication. Are you using OAuth? If yes, prefer signature based auth, because you can then write the cryptography code once and provide it to all your clients. Do you provide a client library to access your APIs? JWT works best for single use tokens. Ideally, a new JWT must be generated for each use. Acceptable use cases: Server-to-server API calls, where the client can store a shared secret and generate a new JWT for each API call. Generate links that expire shortly — such as those used for email verification 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: The Consumers or the user-specific data is exposed by your API Some of the user-specific data is being accessed by third-party developers that you don’t trust 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.

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

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

Too Long; Didn't Read

HashedIn Technologies

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

HashedIn Technologies

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES