API Keys
The downside to usign Refresh tokens and Access tokens with OAuth
The downside to using Refresh tokens and Access tokens with OAuth is, this causes a lot of developer friction. One of the biggest pain points of OAuth for developers is you having to manage the refresh tokens. You push state management onto each client developer. You get the benefits of key rotation, but you’ve just created a lot of pain for developers. That’s why developers love API keys. They can just copy/paste them, slap them in a text file, and be done with them. API keys are very convenient for the developer, but very bad for security.
OAuth Tokens vs. API keys
User-specific authentication is a hallmark of bearer token usage (OAuth).
API keys are used for identifying and authenticating the application or client rather than an individual user. They are static and their scope is for a set of APIs.
With API kets expiration happens manually.
API keys define the source of the requesting entity (e.g. a UI application or one orchestrator application making requests to backend applications), whereas tokens identify individual users and their rights.
API keys are relatively static. While you can and should rotate API keys, you have to build the infrastructure to do this yourself. API keys are not time-bound unless you also build this into your system.
API keys are “secrets” and should be managed as such. Just like the OAuth client secret, API keys are privileged data, which means you can’t, for example, store them safely in JavaScript. Therefore, they limit your architectural flexibility.
There also is no encoded information in an API key, unlike tokens, which may have encoded information, especially if an access token is a JWT. This richer data format can include useful business-specific information such as a todo app subscription level. It also allows for authorization to be performed without requiring “phoning home” to the the OAuth server which created the token.