I have worked on many API integrations scenarios and I used 2 approaches to authenticate the API calls:

  1. Using API Keys

    For example inside Hubspot integration I use this web call to get all the accounts using API Key:

  2. Using OAuth

    For example inside SharePoint I create an app which generates a ClientID & ClientSecret, then inside my project's web.config I store the clientID & ClientSecret

    <appSettings file="custom.config">
     <add key="ClientId" value="e****7" />
     <add key="ClientSecret" value="**=" />

In both cases we have confidential info passed/stored, either APIKey or ClientID and ClientSecret. So from a security point of view, is it true that using oAuth isn't more secure than using APIKeys? Because if a malicious actor gets the APIKey then they can access our application but if they get the ClientID and ClientSecret then they can also access it.

3 Answers 3


In my understanding an OAuth token is in fact an API key. Basically it is a static long seemingly random string, that allows you access to an API. So it roughly does the same like a self made API key.

But in contrast to an API key, which is not more specifically specified, the OAuth token is a standardized object. The OAuth token also e.g. contains a runtime (after which it is not valid anymore) it contains scopes, i.e. the token itself contains the information, what the bearer of the token is allowed to do. I.e. you could get an Oauth token, that allows you to read pictures from your online service but that does not allow you to change pictures.

Remember: OAuth is for authorization, not for authentication.

Of course you can do all this with an unspecified API key, but then you would one day end up with a kind of proprietry OAuth token.

Well, as @mentallurg pointed out, you should not pass an API Key in a GET Request anyway, since the GET parameters can be written to the webservers log. Pass all sensitive information as data in a POST request.


OAuth services like Google or FB, or self made OAuth services based e.g. on Keycloak provide very often following features:

  1. Possibility for the users to reset their passwords, where as it is hard or impossible to reissue an API key.
  2. Password reset can be done quickly, where as re-issuing f an API key may take days or weeks, depending you capacity of your customer support team.
  3. Passwords are stored in a hashed form. If password database stolen, it will not reveal passwords and will not help attacker. Where as when the database with API keys is stolen, the attacker can use all API keys.
  4. If the database with API keys is stolen and user accounts abused, it will be very hard to know where the problem is. You will suppose users didn't care about keeping their passwords safe. Users will suppose you have security problems on your side.
  5. The OAuth service can provide 2FA, where as with API key there is single authentication factor only.
  6. In case your application logs requests, also API keys can be logged. Via logs and their backups more people can know the API keys on your side. You need extra efforts to make sure that API key is not written to the log. Where as in case of OAuth your application only obtains a token containing user ID. Thus it is safe to write the whole request to the log.


All these advantages will be really advantages, if you use some quality OAuth service. If you use the strange approach that you described, with passwords hardcoded in config files, there will be no big difference between two approaches.


The main difference is that the client secret is normally something that has to be remembered by a human being. Because of that, it is hard to find good passwords, and most users do not change it very often and can share it across independant systems.

In the opposite, an API key is something that is (randomly) generated by a computer and is then stored on another computer, so it can be arbitrarily complex and truely impossible to remember for the average human being. And it can only be used for one single system. Every API key will respect all the rules for good passwords just because of the way they are generated. On decent systems, you can renew an API key at will in just a few clicks to get a brand new one, and the server only stores a hash of the key.

But in both case, you have a secret that is stored in clear text in a file, so that file should be protected against the expected threats. Which depends on the real use case.

Anyway, my opinion is that true secret passwords should be used by humans, and that unattended applications should use API keys whenever possible.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .