Normally, when you perform sensitive actions on a website, such as changing your password or enabling two factor authentication, you are required to reenter your password, presumably to protect against session hijacking (either due to interception or someone physically using the computer). However, if a user registered using OpenID or using an OAuth authentication provider such as Google or Facebook, reauthenticating has limited use against someone physically using the computer because the user is still likely to be logged into their Google/Facebook/etc account, so there is no password reprompt. It would still protect against a session ID being stolen and used to add a local password, but if the site operates over HTTPS then this isn't a major concern.

Is there any way to verify the authenticity of the request to, for example, add a local password to an account that has previously only used an external service to authenticate logins, or is it just a risk that has to be taken?

  • Well changing a pw wouldn't apply for OpenID would it? As that is done externally. Adding 2FA (presumably OpenID and something else), you would surely simply re-request authentication against OpenID. Or if allowed access to an email/phone, use that as a 2nd factor. Sep 10, 2016 at 16:38
  • "if the site operates over HTTPS then this isn't a major concern" - not entirely true. Depends on the security required. HTTPS isn't that hard to MiTM attack in many cases. Sep 10, 2016 at 16:39
  • @JulianKnight If you are adding a local password to your existing account, I would consider that to be an operation that requires extra authentication, because it would grant someone full, perpetual control over the account, just like changing a password would. I am aware that HTTPS doesn't grant perfect security, but it does help a lot, and make stealing a session much less likely.
    – JackW
    Sep 10, 2016 at 17:22

1 Answer 1


It is reasonable to think that a particular user may have many different privileges on a site, some of greater and some of lesser sensitivity. In OAuth land, the dance delivers a token to the user, and the site against which the token is valid will have defined the privileges that token enshrines.

So the site can decide to just include privileges tied to the specific request the user made that initiated the OAuth dance, which can be narrower than the full set of rights that that same user may have on the site.

Should then the user- whose authorization is embodied in that token- desire to perform some action that is not permitted by the privileges provided by the token, the site can refuse to allow them to perform the action, and can provide the user with another opportunity to re-initiate the OAuth dance, even if that involves the user re-entering their same credentials.

This isn't great for usability, but it is permissable.

That said, the specific cited circumstance- changing a "local" credential- should perhaps not be thought of as a problem to solve. Multiple sources of truth for authentication are often not a good idea.

You must log in to answer this question.

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