16

From all the research that I have done, I have found that API keys are less secure than access tokens (under usage of oAuth), and should only be used for monitoring purposes.

But from what I understood, the server generates both of them. So if I were to use the same tough algorithm to create my access token, or to create the API key, wouldn't that make them similar? Examples would help the cause of understanding them better as I didn't find any.

Some of the references: https://cloud.google.com/endpoints/docs/when-why-api-key https://zapier.com/engineering/apikey-oauth-jwt/

Elie Saad
  • 347
  • 2
  • 3
  • 14
  • 3
    "From all the research that I have done, I have found that API keys are less secure than access tokens" - Got any references? A token or key (or whatever you want to call it) is used for authentication purposes. The implementation of how the key is created, stored, used, updated, and destroyed is going to be what determines the security of it. – ISMSDEV Jun 14 '17 at 08:06
  • @ISMSDEV I edited the details, added only those I remember. If you care for more, let me know so I can get them. – Elie Saad Jun 14 '17 at 08:10
  • 1
    Do you know the difference between API keys and access tokens? I think you might be confused about what makes the difference between the 2. – schroeder Jun 14 '17 at 09:11
  • @schroeder I am indeed confused about them. From one documentation you read a certain definition, later in an another they mix them up. And most of them agree on API Keys are less secure. And from what I have accumulated, I figured that both can be configured by the developer. This is exactly what I am asking for, a clear understanding on their differences. – Elie Saad Jun 14 '17 at 09:13
  • @ISMSDEV From what you said, we can say they are the same? If yes, why is it that everyone gives differences and yet the developer seems to be behind handling them in the way he wants it? – Elie Saad Jun 14 '17 at 11:46
  • 1
    Sorry I didn't mean they were the same at all. I was trying to answer the "which is more secure", and by that I was trying to articulate the answer is how they are used. They are different and therefore a like for like comparison is not straight forward. – ISMSDEV Jun 14 '17 at 12:02
  • 1
    tokens let your users safely connect directly to an API, keys require secret-hiding server proxying – dandavis Jun 14 '17 at 15:47
  • I would add a little more semantic clarity as well. We think of Keys as being unique and Tokens have no need to be unique. Keys uniqueness should be enforced where Tokens are just statistically improbable to collide, but it shouldn't matter.. A single key should unlock only one thing and whoever gets the key needn't even need to know what it opens. With a token you also need to declare who you are and what you want and the token proves it. – Menace May 22 '19 at 15:45
  • This comment section claims literally the opposite of the accepted answer. Are keys unique or not? Are tokens unique or not? – hraban Jul 17 '20 at 07:22
  • @hraban The last comment, which is posted in 2019, is only one discussing uniqueness, not the `comment section`. Tokens, or keys, are used to identify an entity, or to assign certain security measures. An example: I have a public dashboard for demo, and I provide testers with an API key to gain certain power. That API key is public, unique, and has access controls specific to it. They need to be unique, both tokens and keys, so they only point to a specific control mechanism, whatever that is. Tokens expire fast, maybe that's what the last comment was about. – Elie Saad Jul 18 '20 at 16:27

2 Answers2

14

API keys are public, by intent. They are an authorisation mechanism, not an authentication mechanism (this is mentioned in your links). It does not matter how they are generated but it matters how they are handled. In other words: "anyone with this key can enter".

So, you use API keys when you want to authorise and do not need to authenticate. You use authentication tokens, which are secured in handling, to authenticate the connection. In other words, "here is your unique key to allow you to enter this time".

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 2
    where is it written that by intent they are to be public? API keys are authorisation mechanism that can be public or private, based on the use case. The public ones are used for demos, to help identify an entity but is becoming rare (linkedin was using that), or combined with secrets communicated privately, so what exactly are we referencing in here? They can be so much more, so I believe this could be explained or referenced a bit for readers to understand it better. – Elie Saad Jul 18 '20 at 16:30
2

A typical API key for a REST-ful application usually happens to be significantly less secure than the access control provided by an OAuth JWT (JSON Web Token) for reasons pertaining to application layer protocol messaging (ordering, syntax, data unit protection--or lack thereof), as opposed to protection resulting only from the use of a particular cryptographic algorithm, mode and/or key size. However, I wouldn't be surprised if API key string generators were more predictable than OAuth access token string generators. API keys are often sent as HTTP GET query parameters within an HTTP request's first line as shown here with the Google Maps JavaScript API:

<script async defer src="https://maps.googleapis.com/maps/api/js key=YOUR_API_KEY&callback=initMap" type="text/javascript"></script>

Due to the fact that the API key string is being passed as an HTTP GET query parameter, it is much easier for intermediate web servers (including proxies), and browsers with client-side scripting languages such as JavaScript or ActionScript to gain read and/or write access to the API key. Compare this to other types of HTTP actions such as PUT or POST where the query parameters are more tightly concealed from the aforementioned technologies. Almost all web server software will write the src attribute value in the script tag above to access_log and/or error_log files including the API key, as the query parameter variable values are part of the CGI (Common Gateway Interface) environment variables: SCRIPT_PATH and QUERY_STRING. Refer to CWE-598 for more information.

OAuth access tokens on the other hand, are generated on a per-session basis. Being granted an access token by a secure authentication provider will not occur, until the provider has received proof that the requesting user is entitled to requested privileges; such proof might be established through knowledge of credentials (i.e. a corresponding username and password pair.) Other times, access control might be more restrictive and access tokens are only provided for a small sub-set of privileges within a particular app/site/API sub-component, area of operation, control sphere, etc. The permissions ultimately granted to the end user can be as fine-grained as the system administrator wishes. Note that access tokens are programmed to expire after a set amount of time and are capable of providing discretionary access control between various users/groups, privileges/capabilities, etc.

Access tokens are often transferred outside of the URL in the HTTP request header's Authorization field, for example. Sometimes, custom authentication framework implementations will cause the token to be transmitted within a cookie that has the HttpOnly, Secure and SameSite flags enabled--or as a custom HTTP request header such as X-Auth-Token as publicly documented for Oracle's Cloud Storage SaaS: Oracle's Cloud Storage Service API:

It is extremely rare for HTTP request headers and cookie values to be logged by web browser/server software; they're also more difficult to access programatically due to CORS (Cross Origin Resource Sharing.) In comparison, the API keys passed as HTTP GET parameters can be extracted with client-side JavaScript from the DOM (Document Object Model).

For these reasons, the complexity required to obtain access tokens from an authentication framework such as OAuth is much higher than what is needed to log the usage of an API key. Furthermore, the robustness of authentication and authorization frameworks allows the access token to be encapsulated within the HTTP protocol in ways that it is rather difficult to view or tamper with the token.

Derek Callaway
  • 71
  • 3