Understanding REST API Authentication

# Understanding REST API Authentication Authentication answers "who is making this request?" Authorization answers "what are they allowed to do?" REST APIs typically use one of a few standard approaches to handle the first question. ## Session-Based Authentication The server creates a session on login and stores a session ID in a cookie. The server keeps session data in memory or a database, and the cookie is sent automatically with every request. This works well for traditional server-rendered apps but requires shared session storage across multiple servers, which adds complexity in distributed systems. ## Token-Based Authentication (JWT) Instead of server-side session storage, the server issues a signed token containing user information. The client sends this token with every request, usually in an `Authorization` header: ``` Authorization: Bearer eyJhbGciOiJIUzI1NiIs... ``` The server verifies the token's signature without needing to look anything up in a database — making it stateless and easier to scale horizontally. ## API Keys Used mainly for machine-to-machine access rather than individual user login — a fixed key identifies which application or service is calling the API, often with rate limits attached. ## OAuth 2.0 Used when a user wants to grant a third-party app limited access to their account without sharing a password — the "Sign in with Google" pattern is built on OAuth. ## Choosing an Approach Session-based auth suits traditional web apps with server rendering. Token-based auth suits SPAs, mobile apps, and microservices where statelessness matters. ## Conclusion There's no single "correct" authentication method — the right choice depends on your app's architecture, not just security preferences.