Does signing in via OAuth 2.0 compromise account security if the OAuth 2.0 service decides to become malicious?

Question

Say we signup and login to an OAuth 2.0 enabled security application called "AI Car Command Center" via Google OAuth 2.0

We then logout.

Does Google then have the capability to then grant itself access to "AI Car Command Center", if it was forced to by some entity, of course without the account owner's consent or credentials?

Examples of popular OAuth 2.0 services include:

• Google
• Facebook
• Github

For example this is a possible attack on the OAuth 2.0 login flow:

1. BadOAuthCompany goes to "AI Car Command Center" and clicks login via OAuth button.
2. "AI Car Command Center" redirects to BadOAuthCompany to login.
3. BadOAuthCompany generates for its self an valid OAuth grant token for a user that has registered with them, but without the user's consent
4. "AI Car Command Center" validates Google token
5. BadOAuthCompany then has full, unsolicited access to "AI Car Command Center"?

We can mitigate this by adding 2FA (TOTP) among other techniques. As a sub question, it may be useful to mention these briefly.

Also, it was mentioned that OpenID is a more appropriate protocol for identity verification rather than OAuth2.0

Answer 1

The explanations in this answer are a bit imprecise and simplified to make them more understandable for someone that has only basic knowledge of OpenID and OAuth.

I assume that you are talking about OpenID instead of OAuth. OAuth is used when for example a google user delegates access to parts of his account to you - for example to allow you to see his contacts in GMail.

You use OpenID when you want to know about the identity of someone. In that case you tell OpenID provider that you want to know the identity of the current user. The OpenID provider then sends you a token that holds information about that user - after the user logged in at the OpenID provider.
You then read that token and identify the corresponding user in your database. If that is successful the user is logged in within your application.

In this process you obviously trust the information in that token. The OpenID Provider has created that token. So you trust the information provided by the OpenID Provider.

In the end the OpenID Provider could create malicious tokens faking someone else's identity. However - without the presence of a vulnerability in your application or the OpenID Provider - an active attacker within the OpenID Provider would be necessary.

Answer 2

It looks like a should I trust xxx question. And in fact, when an application service delegates its authentication to an OAuth 2.0 provider, it means that it does trust that provider.

Among what the OAuth 2.0 provider could do:

• reject valid authentication request leading to something close to a Deny Of Service
• log valid user names and then decide to later allow them whatever the password (when the request comes from some origine they know) allowing attackers to impersonate legitim users

Well known OAuth providers really do not want to go that way, because the application services are their customers and they need that customer relationship. But whether you can trust them is a true security problem and should be handled with the usual questions:

• what is the threat
• what is the risk (photos of my pets could be compromissed or a nuclear weapon could be launched)
• what attackers do I want to be protected from (my 12 years cousin or the CIA/NSA)

For light to medium security needs, well known public OAuth 2.0 provider can probably be trusted, for organization strategic or national defense security ones, they should not.