The app for independent voices

๐—ช๐—ต๐—ถ๐—ฐ๐—ต ๐—ฅ๐—˜๐—ฆ๐—ง ๐—”๐—ฃ๐—œ ๐—”๐˜‚๐˜๐—ต๐—ฒ๐—ป๐˜๐—ถ๐—ฐ๐—ฎ๐˜๐—ถ๐—ผ๐—ป ๐— ๐—ฒ๐˜๐—ต๐—ผ๐—ฑ ๐—ฆ๐—ต๐—ผ๐˜‚๐—น๐—ฑ ๐—ฌ๐—ผ๐˜‚ ๐—จ๐˜€๐—ฒ?

Not all authentication methods are created equal. Therefore, an improper choice could leave your API unsecured or make your architecture overly complicated.

Here are ๐Ÿฑ ๐—ฎ๐˜‚๐˜๐—ต๐—ฒ๐—ป๐˜๐—ถ๐—ฐ๐—ฎ๐˜๐—ถ๐—ผ๐—ป ๐—บ๐—ฒ๐˜๐—ต๐—ผ๐—ฑ๐˜€ and when to use each:

๐Ÿญ. ๐—•๐—ฎ๐˜€๐—ถ๐—ฐ ๐—”๐˜‚๐˜๐—ต

Sends username and password in each and every request in the ๐—”๐˜‚๐˜๐—ต๐—ผ๐—ฟ๐—ถ๐˜‡๐—ฎ๐˜๐—ถ๐—ผ๐—ป header. Easy to implement, but sends credentials with every request. To be used only when deployed over ๐—›๐—ง๐—ง๐—ฃ๐—ฆ and for internal usage only.

๐Ÿฎ. ๐—ฆ๐—ฒ๐˜€๐˜€๐—ถ๐—ผ๐—ป ๐—”๐˜‚๐˜๐—ต

The server establishes a session after authentication and tracks it by sending a ๐—ฐ๐—ผ๐—ผ๐—ธ๐—ถ๐—ฒ to the client's browser. For web applications where both frontend and backend are deployed at the same origin, this is an acceptable choice. For mobile and microservices architectures, sessions are not recommended because they do not scale horizontally.

๐Ÿฏ. ๐—ง๐—ผ๐—ธ๐—ฒ๐—ป ๐—”๐˜‚๐˜๐—ต (๐—๐—ช๐—ง)

The user logs in once and receives a ๐—๐—ฆ๐—ข๐—ก ๐—ช๐—ฒ๐—ฏ ๐—ง๐—ผ๐—ธ๐—ฒ๐—ป. The user sends this token in the header for all subsequent requests. The system is stateless and scalable. The server does not have to store sessions. This is the go-to authentication mechanism for modern APIs and SPAs.

However, be careful about token expiration. The standard practice is to use short-lived tokens with a refresh token.

๐Ÿฐ. ๐—ข๐—”๐˜‚๐˜๐—ต ๐Ÿฎ.๐Ÿฌ

This authentication mechanism allows users to grant third-party applications limited access to their data without sharing their passwords. The process involves authorization grants and access tokens between multiple parties. This authentication mechanism is used when you want to provide delegated access.

Think of "Login with Google" or third-party applications accessing your API.

๐Ÿฑ. ๐—”๐—ฃ๐—œ ๐—ž๐—ฒ๐˜† ๐—”๐˜‚๐˜๐—ต

In this mechanism, a unique key is passed as a header or as a URL parameter to identify the ๐—ฐ๐—ฎ๐—น๐—น๐—ถ๐—ป๐—ด ๐—ฎ๐—ฝ๐—ฝ๐—น๐—ถ๐—ฐ๐—ฎ๐˜๐—ถ๐—ผ๐—ป. This is a good mechanism for server-to-server communication and for client rate limiting.

However, avoid using this mechanism as the primary user authentication method, since an API key is not a user representation.

Quick rule: JWT for most APIs. OAuth when third parties need access. API keys for service identification. Session auth for traditional web apps. Basic auth only when nothing else works.

What authentication mechanism are you using for your current project?

Feb 9
at
7:37 AM
Relevant people

Log in or sign up

Join the most interesting and insightful discussions.