API Key vs Session Token vs Access Token: What's the Difference?
Open the developer settings of almost any web service and you'll be offered some combination of an API key, a token, and a secret, usually with no explanation of why there are three different words for what looks, at first glance, like the same thing: a long random string you're supposed to keep safe. They aren't interchangeable though. Each one is built to answer a slightly different question about who, or what, is making a request.
An API key identifies which application is calling a service and typically lives for a long time. A session token represents a logged-in browser session and is short-lived by design. An access token represents a specific, scoped permission, usually issued through OAuth after an authentication step. All three are long random strings, but they answer different questions: what app, which session, and what permission.
What is an API key actually for?
Every developer working with third-party services has a drawer, metaphorically, full of API keys. These long random strings authenticate software to other software. When your weather app requests the current temperature from a weather service, it includes an API key in the request. The weather service checks the key, confirms it belongs to a legitimate registered application, and responds. Without the key, the request is rejected.
An API key is essentially a password that a program uses instead of a human. The difference from a traditional password is entropy: a well-generated API key is typically 256 bits of randomness, compared to a human-chosen password that might have 30. There's no vocabulary list, no birthday, no significant other's name, just randomness, and API keys are usually meant to stay valid indefinitely until someone deliberately revokes them.
How do session tokens actually keep you logged in?
HTTP, the protocol of the web, is stateless, each request is technically independent, with no built-in memory of previous requests. When you log into a website, the server generates a session token: a long random string that it stores on its end and sends to your browser as a cookie. On every subsequent request, your browser includes the token in the request header. The server sees the token, looks it up in its session store, and knows who you are.
The token is not your password, it's a temporary, disposable representative of your authentication state. When you log out, the server deletes the token from its store, and the cookie in your browser becomes meaningless. This is why you can be logged into the same account on multiple devices simultaneously, each device has its own token, and why logging out of one device doesn't log out the others unless the server explicitly invalidates all tokens.
What makes an access token different from both of those?
An access token most commonly shows up in the context of OAuth, the standard that lets you click "Sign in with Google" and grant one app limited permission to act on your behalf with another. Rather than handing your actual Google password to the requesting app, you authenticate directly with Google, and Google issues a short-lived access token scoped to specific permissions, read your email, see your calendar, whatever you approved. The requesting app never sees your real credentials at all, only this narrowly scoped, expiring token.
The scoping is the key difference from an API key. An API key usually grants broad access to whatever that key is allowed to do. An access token is deliberately narrowed to exactly the permissions a user approved, and it expires far sooner, often within an hour, requiring a refresh token to get a new one without asking the user to log in again.
Which one should you actually build for your own service?
For a simple server-to-server integration where you control both ends, a single long-lived API key is often genuinely simpler and perfectly adequate. Reach for OAuth-style access tokens when a third party needs to act on behalf of a specific user without ever seeing that user's real password, or when you need fine-grained, revocable, expiring permissions rather than an all-or-nothing key. Session tokens aren't really a choice at all, if you have logged-in human users in a browser, you need some form of session token regardless of what else you build.
Whichever you need, the generation principle is the same across all three: long, genuinely random, and never derived from anything guessable. You can generate properly formatted API keys, session tokens or general-purpose tokens on this site for testing, documentation or prototyping, entirely client-side.
Frequently Asked Questions
Is an API key the same as an access token?
They're related but not identical. An API key is usually long-lived and identifies which application is calling a service. An access token is typically short-lived and represents a specific, scoped permission granted after an authentication step, most often via OAuth.
Why do session tokens expire so much sooner than API keys?
A session token represents a temporary logged-in state for a human sitting at a browser, so it's designed to expire quickly and get replaced constantly. An API key represents a permanent relationship between two systems, so it's designed to stay valid until deliberately revoked.
Can I use an API key instead of implementing OAuth?
For simple server-to-server integrations, yes, an API key is often simpler. OAuth access tokens are worth the extra complexity when you need fine-grained scopes, token expiry, or when a third party needs to act on behalf of a user without ever seeing that user's actual credentials.
What's the actual difference in entropy between an API key and a password?
A well-generated API key is typically 256 bits of pure randomness. A human-chosen password might carry 30 bits or less, since people gravitate toward memorable words, dates and patterns rather than true randomness.
Why can I be logged in on multiple devices at once?
Because each device gets its own independent session token when you log in. Logging out on one device deletes only that token from the server's session store, leaving the tokens on your other devices untouched, unless the server is explicitly told to invalidate all sessions.
Is it safe to put an API key directly in frontend JavaScript code?
Generally no, for a key that's meant to stay secret. Anything shipped to a browser is visible to anyone who opens the developer console. Secret API keys belong on a server; only keys explicitly designed to be public, often rate-limited and scoped down, belong in frontend code.