Post History

> - If I am not already logged in at `bar.com`, I should always log in separately before attempting to authenticate, correct? There is no way that `foo.com` can provide me with a login window and prove to me that it's secure (i.e., that they aren't MITMing me)?

The login window is from `bar.com`, the Identity Provider (IdP). The `foo.com` site typically sends you to `bar.com` to do the sign-in.[^popup] You do need to make sure that it's not sending you to a lookalike URL,[^lookalike] but the certificate should all be fine.

> - Similarly, if I believe I'm logged in at `bar.com` already, but trying the `foo.com` authentication link gives me a login form, I should reject this and treat it as a phishing attempt, correct?

It's certainly fishy, but it's the same situation as above. You _should_ be able to tell that you're on the right site with the certificate and verifying that it's not using lookalike characters[^lookalike] in the domain.

> - When I give `bar.com` permission to authenticate me to `foo.com`, how do I know that this won't compromise my `bar.com` login? What information is actually communicated per the OAuth protocol?

Sorry for non-technical description. For straight OAuth, it's basically "I'm `bar.com`, and I vouch that the person is Identity `X` to me." It does not send any part of your authentication to `bar.com`, just a confirmation that you exist as an account there.

Lots of sites bolt some _authorization_ on top of the _authentication,_ which lets them also say "and here is the list of things my user says you can ask from their account and/or do to their account." In those cases, `foo.com` has to ask for the permissions, and `bar.com` shows them to you to grant or deny. Some sites may allow you to choose which things to grant. Some may just let you accept/reject the whole slate. If `foo.com` asks for things you didn't expect, maybe it's not a service you should trust.

> - When I give such permission, typically `bar.com` will warn me that `foo.com` wants permission to access (or know) certain information about my `bar.com` account. How can I be sure that only that information is being transmitted?

You don't, really. You can make your own requesting site, though, and see that it really does only give you the things that you agreed to on `bar.com`.

Like any software, it _can_ do all sorts of things, and they _can_ be unsafe. And since it's a website, the software can change at any time. All of this is incumbent on `bar.com` not doing the wrong thing, though. None of it depends on `foo.com` (though you hope `foo.com` doesn't leak data either).

> - Could `foo.com` ever gain the ability to modify my `bar.com` account information?

Yes. See above. I don't think it's strictly a part of OAuth, but many sites basically issue permissions (that it asks _you_ about, on first registration), to do things like load your profile picture or integrate with your calendar on `bar.com`. Or it can wait and ask (with a new interstitial) for permission to do that later, after your first registration.

> - Could it happen that the authentication appears to just work without me giving consent on a `bar.com` interstitial? If that happened, what should I do?

I wouldn't expect that the first time, but as above: software _can_ do anything, so `bar.com` _could_ do that. After the first registration, yes, I'd expect it to bounce between `foo` -> `bar` -> `foo` when you load up a `foo.com` page, and do all that seamlessly.

If it happened the first time you registered (or if you revoked `foo.com` access), I'd complain to the owners of `bar.com`. That would be a security hole in their site.



[^popup]: Sometimes the requesting site opens a popup of the IdP, but I don't like that as much.
[^lookalike]:  `b4r.com` or worse: math or other-alphabet (Cyrillic?) symbols that look the same as the characters in the "normal" trusted URL.