如果服务器本身遭到破坏，它们看起来确实很相似，但是如果您认为违反行为发生在通信渠道中，则会有一些细微的差别.

使用基本身份验证，完整的凭据始终包含在每个请求中，而使用OAuth，则是每个请求中包含的访问令牌.乍一看，这似乎是相同的，但是令牌确实具有一些有趣的特征:

• 它们可以具有相关的到期时间，从而减少一次泄漏的影响.
• 它们的范围可以缩小，即应用程序具有写访问权限，但是由于大多数请求仅需要读访问权限，因此它请求的是在大多数请求中使用的只读访问令牌；再次使泄漏的影响最小化.

另一个有趣的部分是，大多数漏洞很可能发生在通信通道中，而不是在服务器本身上，因此这确实很重要.

但是有一些缺点，如果您需要立即吊销功能，则承载令牌还需要一些额外的复杂性.

Is OAuth more secure than Basic Auth through HTTPS for server to server dialog?

I mean, if I want to do some API request from server A to server B with OAuth, I have to store some auth data (key, secret, etc.) on server A. Then using these auth data, I can have a token and make requests with this token to server B. And using the same auth data later, I will have a token key and will be able to make request with this fresh token.

With Basic Auth, I have some auth data (user, password) on server A. And I can perform requests with this data on B now and later.

Now let's say the auth data is discovered because there is a file on server A .conf with the auth data and this file was stolen. In both case (OAuth and Basic Auth), that's terrible, and there is no benefits in using OAuth over Basic Auth. Example on a real case: I just created a twitter bot (connection with OAuth) some days ago, if the configuration informations are discovered, the account is stolen and the attaquant will be able to use this bot now and in the future.

So, is there another reason I don't know (or maybe I misunderstood something) in using Oauth over Basic Auth for server to server requests (with HTTPS)?

If the server itself is breached, they do seem similar, but there are small differences if you consider the breach is in the communication channel.

With Basic authentication the full credentials are always included in each request, while with OAuth it's the access token that is included in each request. At first glance this may seem the same, but tokens do have some interesting characteristics:

• They can have an associated expiration time reducing the impact of a single leak.
• They can have a reduced scope, that is, the application has write access, but since most of it's requests only require read access, than it requests a read only access token that it uses in this majority of requests; again this minimizes the impact of a leak.

Another interesting part, is that most breaches will likely occur in the communication channel and not on the servers themselves so this does seem important.

There are however some downsides, bearer tokens require some additional complexity if you need immediate revocation capabilities.