When we login to a service via a user account, we are normally required to provide an email and password (and on some occasions a username as well).
But, when one website's API authenticates to another website's API (automatically), a personal email address can't be used since it's not a human doing the authentication.
Is the API key then some sort of "machine username" replacing a typical (human) username?
The best description of an API key I can find comes from this article from Apipheny:
When dealing with APIs, you may encounter something called an API key. They’re sort of like passwords which let APIs confirm your identity. Once an API knows you’re legitimate, you can get through and use the API’s full set of features.
Example of an API key: 1f9ba190-c513-471b-a573-b8d008bb52fe
Usually, the API key is a single token that’s used to access the REST API. In the computing world, a token is an object that represents the right to perform an operation.
By putting two and two together, we can infer that an API key is a code that gives us the right to access an API.
So, the key takeaway (pun intended) is that an API key is something you generally use instead of a username/password combo when you're authenticating to an API. They are used because compared to a username/pass combo:
You can rotate them independently of your usual login details. So, if your API key gets compromised, you can log into the service and generate a new API key.
Some companies let you create multiple API keys, each with different privilege levels within your account. This reduces surface area for attack, since you could for instance generate a key limited to read-only account access.
Since, for some projects, your API key needs to be stored on your own server to be useful, it gives you an extra layer of security since you don't need to store your username and password there.
API keys are a lot like passwords: They are secrets that allow access.
There are however a few differences:
The term "API key" is overloaded for two very different meanings. In your case, it's not entirely clear, but from
when one website's API logins to another website's API automatically
(emphasis mine) I gather that you're talking about logging in from the server side, in which case Maximillian's and Stephen's answers are right.
However there's also another, possibly older and arguably more common definition of "API key", where it's not a key at all, because it's not secret. This is what Nat seems to be talking about.
For example, if you wanted to access some third party's web-based API from the client side of your web application, or from an application running on the user's PC or phone, any "key" is something you ship to the user, which they're able to reuse for any purpose they like, not just the purpose you intended. This "API key" may be used for access only to unprivileged interfaces (think Google Maps) or may be accompanied by a login specific to the user (not to your application) with the API provider.
Why have this sort of "API key" at all if it can't have any secrecy and provides no meaningful access control? I have a Twitter thread on the topic where I described it as "low-grade accountability in a walled garden". Basically, the API provider is making anyone who wants to integrate with their service get an identifier so that all use associated with their application can be tracked, monitored for misuse, and cut off if the API provider suddenly decides they don't like what the application is doing. Yes, a skilled person can extract the identifier from an application and use it for their own purposes, but the scale of this is expected to be limited; if they ship an application with someone else's API key, there is clear public evidence they did so, and they're likely to face legal problems.
Unfortunately, this has two really bad side effects:
Calling it a "key" is extremely confusing to programmers using the API, especially when you're telling them to embed it in their client-side application code. This leads directly to programmers putting actual credentials (the other kind of "API key") in their client-side code because they don't understand the difference.
Since API providers insist application developers keep their keys private, despite that being impossible, and only use them for one application, it locks out open source applications from shipping source in a form where it builds and works "out of the box" without the user having to obtain their own key.
One important thing to understand is, that there is a difference between authorization (you are allowed to do this thing) and authentication (you really are who you say you are). They are not necessarily tied together. There may be instances where you do not need to know who you are dealing with so long as they provide the right credentials(e.g.. a password for a speakeasy). Or conversely, you may be authenticated but still unauthorized to do a thing(e.g. you have a passport but no license, so you are not allowed to drive.)
Authentication in the real world can be generally broken down to three different kinds of things that you need, in order to prove that you are who you are:
Many real world applications only use one of those, most websites use two, some even need all three. As you might guess, the more of those that you implement/use, the more secure your system becomes. For even more security, you can usually add more things that you have to know or have.
When APIs talk to each other, and one wants to ensure the other is authorized to do this, it needs to provide something that the other can have and give back as needed. This is your API key. How it is derived, and how secure it is, is probably beyond this question and better suited for security.stackexchange.com. Depending on the security needs of the system, this may be enough for authorization.
Authentication usually works by only allowing specific IPs or domains to access a service, or by using public key authentication.
In this light, you I would say it is something you know, so a password. It does not authenticate you, it authorizes you.
An API represents an authorized entity. As such it is more analogous to a username+password
Of-course this is a bit of a generalization as different systems may attach different exact meanings to this - however to the extent this is inaccurate an API key might be more representative of a password then a username.
tl;dr– An API-key is an identifier, typically for an API and possibly associated data. They're not for secure-authentication, though they may offer some security-through-obscurity under certain conditions.
Apparently, API-keys are just identifiers. They're analogous to user-names, account-numbers, social-security-numbers, etc.. That's really it.
While modern security-practice would hold that API-keys are unfit for secure-authentication, they can offer some security-through-obscurity if not widely disclosed.
Analogies for this security property:
Social-security numbers in the United States.
In the United States, people get a nine-digit identification-number called their social-security number (SSN).
Folks had often advised keeping this secret to hinder identity-theft. Because, while the SSN is an identifier and not really a secret (folks have to disclose them to their employers, banks, etc.), it can still be a hindrance to identity-thieves if they don't know a would-be-victim's SSN.
Secret-doors without locks.
A secret-door without a lock might not be misused if no one knows about it or where it's at.
Of course, it'd often seem more secure to have a lock on the secret-door. Then the door's secrecy could be a compliment, rather than something that'd need to be relied upon.
A hidden key.
Some folks keep a key to their house under the front-mat or other nearby location, sometimes telling family/friends where the keys are.
To be clear: security-through-obscurity can work and can be quite valuable! However, it's generally better understood as a defense-in-depth compliment to another, dedicated security-mechanism. This is, it shouldn't be mistaken for a stand-alone security-mechanism; for example, it's not a substitute for proper authentication, nor is it a password.
In short, they're sometimes-obscure identifiers for API's and related data.
The best way I've heard it put:
Application = hotel
Authentication service = hotel front desk
Application resources = hotel rooms
Access token = room key
Credentials = ID/passport
Check out time = key expiration date
Some areas are public like the bar/grill, and some things are free like a glass of the hoity-toity cucumber water from the glass pitcher by the front desk.
However, to access your room or any of the amenities like the pool or spa you have to swipe your key card. So when you get to the hotel, if you're a legit guest, first thing you want to do is check in and get your room key. Before you leave the desk, the employee says:
"Remember! Your key won't work after 11:30am, make sure to check out on time!"
Any time your key is swiped, the hotel believes it is you.
A week later after you get back from vacation and you're doing laundry you find your hotel room key in your pants pocket. You just toss it - since your stay has ended (and key expired) it's now useless!
