Security risks of OAuth vs a password manager

Of the following two approaches, which is “more secure”, under which circumstances, and why? In other words, please compare the security risks of these two approaches:

  1. Log in to an OAuth provider such as Google or Facebook using a master passphrase; then use OAuth/OpenID to log in to other services via that OAuth provider.
  2. Use a password manager with the same passphrase; have it generate and auto-type a separate random password for each service.

An obvious similarity is that in both cases, only a single master passphrase needs to be remembered by the user. This question explains how OAuth and OpenID work and why they’re considered secure, but it doesn’t compare it to a password manager.


From my perspective as a user, OAuth and password manager solve the same problem of not having to enter separate passwords (or any passwords at all) when logging in to various services. OAuth does it by “reusing” my login into the OAuth provider (I understand the technical details are more involved, but that’s how it looks to me as a user). A password manager does it by automatically typing in the password for me.

Either way, I only need to enter a single master passphrase: either to the OAuth provider or to the password manager.

I’m trying to decide when to use which solution. To do that, I want to understand their security implications more in depth (and compare them where possible).

OAuth vs separate accounts (with separate passwords), as noted by @schroeder , is one aspect of this. But a password manager is necessary to automate the password entry, and adds its own layer of security risks. So it’s also an important piece of the puzzle, I think.

(I apologize if this question looks silly to the more security-educated folk here.)

security – Has OAuth client identity trust issue ever been addressed?

Has OAuth client identity trust issue ever been addressed?

In OAuth authorization model, we know a permission dialog is shown to the user to accept/reject the granular access to specific scope for other service. Now, the only way for user to know about who is going to get the grant from the dialog is the client name shown in the dialog, which is actually a name registered in OAuth server somewhen in the past. I am new to OAuth, however, I see a security problem in this model.

So far I know, there is no way to verify whether the client is actually who it is pretending to be by the name in client registration phase and that is why any company can register well known trustable name against its own. That raises the possibility of stealing confidential data by pretending to be other well known, trustworthy company to the naïve users.

For example, when user see a trustworthy client name in the dialog, i.e. Google, Apple etc. they might have bias to accept some scope which otherwise they would not accept for any other client even when the dialog is accessed and triggered from low grade client site.

Has this issue been ever addressed? Any proposed or implemented solution exists?

oauth – Entering password on third party websites to enable integrations

I’ve got a third party service that I want to integrate with various other websites/applications, the third party service says they support this however rather than using an API key or OAuth to provide this they require you enter your username and password for the website you wish to integrate them with, they say they will encrypt your password using AES-256 and hash it using PBKDF2 hashing, however in my eyes this is still wrong as i’ve always been a believer that you don’t enter your password for one website into another website, this is why things like OAuth exist in the first place.

Is what they’re requesting perfectly legitimate and i’m being too sensitive to security or am I correct in saying this is weird?

Example; Website X asks for my Google username and password to integrate their service with my google account

oauth2 – The trade-off between user-agent risk and client server risk in Oauth 2.0 / 2.1 security framework

Generally speaking we can specify the potential risk into 2 categories: user-agent risk and client server risk.

As for the 3 client types mentioned in section 2.1 of the Oauth 2.1 draft (, only the “web application” may encounters both the 2 risks, while the others (“browser-based application” and “native application”) only have user-agent risk.

user-agent risk: The user-agent environment (browser, app, or the OS they are running) may be not safe. Especially when the client has huge users the probability of this risk is relatively higher.

client server risk: Usually the client server is much more safe than user-agent, so the probability of leaking the access tokens stored in the web server is low.

However if we consider the overall “expectation of loss” for these 2 risks, it’s not sure if the E(S)(expectation of loss for client server risk) is always lower than the E(U) (expectation of loss for user-agent risk).

Let’s say E(S) = P(S) * L(S) and E(U) = P(U) * L(U), where P() means the probability of each risk, and L() means the potential loss if each risk event happens.

As mentioned above the P(S) is much less than P(U) usually, however the L(S) is also much higher than L(U). Assuming a client server is hacked or some bad guys inside the client broken the server, all the users’ access tokens stored on the server will leak and the potential loss L(S) will be much higher. Instead in the user-agent risk scenario, the L(U) would be smaller because just access tokens of some individuals leak.

Especially if we build a fully open platforms through Oauth schema, the P(S) may be not so small because the authorization / resource server owner cannot guarantee each of (we application) client is trusted.

So the questions is: Does it prefer to avoid client server risk rather than the user-agent risk in the latest trend? As we see the authorization code grant is extended with the functionality from PKCE? The PKCE flow can be done from the pure browser / app end (even for the we application client) completely, the server side is not must involved and it cannot store the access tokens then.

Instead in the Oauth 2.0 (RFC 6749, 6750) the authorization code flow has to involve the server side when fetching the access token, because it is dangerous to expose the “client secret” to the user-agent browser / app.

Not sure if this understanding is correct, and could you kindly give some more suggestions for the trade-off between user-agent risk and client server risk when building an Oauth based platform?

How do I profile A REST API request from the Simple oauth module?

I am trying to profile a REST API endpoint (/oauth/token) for performance issue. I want to see what database queries are executed during that API request.

Can I get it using webprofiler with the Devel module?

authentication – While we put elaborate standards to authenticate users (eg via OAuth), why do APIs only need an API Key?

Today, OATH is the standard for Authenticating Users. It employs an elaborate setup to eliminate all vulnerabilities.

YET, when it comes to APIs, the standard is just have an API Key inserted in the HTTP Request Header. Voila, you’re in. This is even adopted by google.

Why is this so? These API endpoints are public!

magento2 – Do Magento 2 Integration OAuth Access Tokens Never Expire?

Hi I just want to make sure that if I created an integration via OAuth authentication

I would use the access token of which for Magento 2 API calls. It is my experience that they never expire, is this claim absolutely true?

Insofar that the behavior is different from the admin and customer access tokens that do expire and have to regenerate a token else get a 401 error

email – WP Mail new version asks for set *their* domain URL as Authorized redirect URI in my Google OAuth 2.0 Client Credential


WP Mail is a WP plugin, and I want to set up it to send emails using my gmail account via gmail API.
So I’ve created a Google project, set it up, including the consent screen and a OAuth 2.0 Client IDs within my project. However WP Mail has hard coded that I have to set the Authorized redirect URIs for the my OAuth 2.0 Client IDs in my Google project to: (and no an url within my site).

Then I had to go through the google usual consent procedure, and state that I trust (instead of my site). I googled and they state: “The change was needed (meaning: use their url instead my own) because a lot of users had issues with mod_security and other security WP plugins which blocked the request Google was sending to the user’s WP site. We fixed this and so you need to add the new redirect URI to the Google oAuth app you created.”


So in my plugin config I gave my Client ID, Client Secret, + confirmed for google, I trust, (as Authorized redirect URI) and gave them right to read, write etc. my email account. I understand that without having set the plugin with my Client ID, Client Secret it would incapable to send email via the API. I also understand, that I can delete this client ID from my project and end of story. However unfortunately I can not evaluate the difference between the Auth URL is my domain or the Auth URI is their domain.

I think this is definitely not the way, but I am not a security expert. Any recommendations?