12

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?

1
  • Seems like a legacy concept. If it doesn't seem to make sense in the context of modern security practices, that's probably why.
    – Nat
    Sep 22 '21 at 4:23
9

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:

  1. 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.

  2. 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.

  3. 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.

6
  • In short, both passowrd and a resource allowcation indicator. Right?
    – almeroz
    Sep 21 '21 at 7:45
  • @almeroz Your api key is what you use to authenticate, similar to a username/password. The API you're using may have limits to how much you can use it, which is often determined by your account's service plan level. Sep 21 '21 at 7:51
  • So the API key is a combo / merge / chimera of a username and password, always? That's nice.
    – almeroz
    Sep 21 '21 at 8:58
  • @almeroz - not quite. It is generally a random set of numbers/letters associated with an account. You wpuld not expect to be able to reverse the useename or password from the API key even if you know how the key is generated. Some API keys (eg the paid Divi module for wordpress) requires a set username + an API key per site - here the API key is acting more like a password - although this is less common then an API key corrolating to username+password. The api key really depends on the API, which is up to the developer to decide.
    – davidgo
    Sep 21 '21 at 12:02
  • 2
    @Ruslan It depends. Some API keys are meant to keep secret, some are fine if shared publicly. It all depends on the purpose of the key and what the key has access to. Sep 21 '21 at 19:17
5

API keys are a lot like passwords: They are secrets that allow access.

There are however a few differences:

  • Passwords are for humans, API keys are for automated access with programs or scripts.
  • Passwords are usually short and simple enough to be memorable. API keys are designed to be used by computers and as such are usually significantly longer, more complicated, and more secure than passwords.
  • Passwords are usually generated by the user. API keys are usually generated by the server and then given to the user. API keys that are generated by the server are guaranteed to be long and random. User chosen API keys would not be.
  • Passwords are almost always used with a username. API keys are sometimes used with a user name, but often have the user information embedded in them.
  • Passwords usually grant full access. API keys are often tailored to access a portion of what a user can access so that if they are compromised, the amount of damage that can be done is limited.
  • A user has one password for a site at any given time, but might have several API keys that allow different levels of programmatic access.
  • A password can be changed, but an API key typically needs to be revoked or invalidated and a new API key issued.
4
  • I tried to change the ordering from ul to ol to ease tracking the sections and possibly commenting, I did so from smartphone and couldn't review, I also can't re-edit until approval or rejection.
    – almeroz
    Sep 21 '21 at 17:22
  • @almeroz I'm pretty happy with an un-ordered list here. The differences from passwords don't have a particular order. An unordered list is more semantically appropriate. Sep 21 '21 at 17:30
  • 1
    Some open-source projects have build instructions that incorporate API keys, e.g. Chromium via BLFS. If an API key is a secret, is this instruction then a leak of the secret?
    – Ruslan
    Sep 21 '21 at 19:10
  • 1
    @Ruslan you had this same comment answered above; in addition to "it depends", I'll say "usually, yes". The secret is linked to an identity, so it's up to the owner, though in this case it's sort of like having a demo user/password posted publicly. The Chromium docs do say "The keys you have now acquired are not for distribution purposes and must not be shared with other users".
    – TylerW
    Sep 21 '21 at 20:59
4

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:

  1. 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.

  2. 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.

1
  • I've heard the term "application identifier" for this type of usage. But I guess if Google Maps calls it an API Key, the terminology isn't standard. Sep 22 '21 at 13:09
2

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:

  1. Something you are (e.g. a username, your fingerprint) This is imperative for authentication
  2. Something you know (e.g. a password)
  3. Something you have (e.g. a key, 2-factor authentication app, ...)

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.

0
1

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.

0

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.


API-keys are just identifiers for API's and associated data.

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:

  1. 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.

  2. 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.

  3. 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.

4
  • 2
    API keys can be insecure in certain circumstances, but I don't believe they are always as insecure as you make them out to be. I think that the Google document you linked is specifically in the context of client API keys which are sent to end users and indeed more like an identifier, but API keys for server-to-server communication (or for clients where each user generates and manages their own unique API key) can be kept much more private and be used more similarly to passwords. Sep 22 '21 at 5:10
  • @MaximillianLaumeister: The idea behind splitting up a user-name and password is that there's a separation between those who know the identity (the user-name) and those who can claim it (via the password). With API-keys, anyone aware of an identify finely enough to explicitly identify it can claim it.
    – Nat
    Sep 22 '21 at 5:17
  • @MaximillianLaumeister: I mean, if GMail allowed it, people could create new GMail-accounts without a password and just hope that no one with knowledge of the account misuses it, but that wouldn't make the user-name a password. Which isn't to discount security-through-obscurity entirely, just, it's a different concept.
    – Nat
    Sep 22 '21 at 5:18
  • 2
    I've added an answer that clarifies some of what I think you were talking about. Sep 22 '21 at 12:59
0

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.