5

Why do some API providers ask you to implement Oauth2 in server to server communication that's available only over HTTPS?

In the frontend (app or webapp), Oauth2 is useful to protect the user credentials by storing a token and not the credentials in local storage, filesystem or cookies, and if there is no https channel is not a good idea to pass the credentials on each call rather than the token that can be revoked or eventually expire.

But why going through the implementation process of oauth2 server side to communicate to another server? Credentials are stored on the server, if there is a breach, well, token or not you are screw, the SSL channel protects you from men in the middle and replay attacks. How is this system more secure using outh2 instead of Basic Auth?

There's a similar question about this topic but with no concrete answer, so I'm trying to bring up the topic again Oauth2 vs APIKey in a server to server communication

DomingoSL
  • 153
  • 4
  • One thing I can think of, regarding the OAuth2 client credentials grant, is that you can have a separate "credentials service" that exchanges client id+secret for an access token. That way, a compromised access token doesn't not equal a compromised client secret. – Daniel Oct 22 '18 at 11:29

2 Answers2

3

If you use "username + password" for auth, sending the password on each request is a problem because authenticating the password is slow because the password is stored using a secure password storage method that is deliberately slow. So you want to use the password once to get a long computer-generated token and send that in the subsequent requests.

The high-entropy (long, computer generated) token can be stored in RAM only or can be stored hashed-once in a database, so validating it on every request is cheap.

It can also be stateless (e.g. HMAC of user id and timestamp, using a key available only to the server) but then invalidation requires storing a blacklist of invalidated tokens instead of whitelist of valid tokens, though hopefully the blacklist is smaller and if the tokens have reasonable lifetimes the blacklist shrinks as they expire.

If you send human-generated password in every request (naive basic auth) - stop. If you send long computer generated token in every request - it doesn't really matter how you format it in the HTTP request. A benefit of using the customary Authorization header is that a bunch of existing code already knows to not log it. Whether you format the token as Authorization: bearer <40char> or Authorization: basic base64(user_id:token or just first-half-of-token:second-half-of-token), it doesn't matter.

The full OAuth2 is too much code (that can contain bad security bugs) if you don't need it, so you can use something simpler (the simpler, the better). But you need to consider at least the cost per-request and how invalidation works.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
0

You are right, there is no real security benefit. Basic Auth is as secure if HTTPS is mandatory. It most likely is just preference, whoever implemented the API decided to only rely on Oauth2 rather than having multiple authentication schemes. Design decisions can vary a lot from project to project and without knowing their circumstances it's hard to tell.