TL;DR: You're not using a passphrase multiple times with OpenID, but have other parties (like Stack Exchange) trust your identity provider (like Google) to be carefully authenticating you. The passphrase (or any other authentication schema like two factor authentication, certificates and so on) only is revealed to the identity provider.
Identity Certifications in the Real World
Similar methods are often used for opening bank accounts, signing up for phone contracts or other actions requiring verification of your identity. If you don't want to go in person to that company, often you can have your identity verified through a notary, post office or bank agency, which will verify your passport (this is like presenting your passphrase to Google), and then hand you (or pass it immediately to the third party requesting authentication) a certificate confirming they checked your identity, but without attaching a copy of your passport.
The idea of OpenID (and similar single sign on technologies) is that you don't enter a passphrase at the target site at all. For example, if you want to log into your Stack Exchange account using Google, Stack Exchange never gets hold of your passphrase, but you get redirected to Google instead, which will authenticate you (possibly you're already logged in to Google, so you might simply be asked whether you want to be authenticated for Stack Exchange and be sent back there).
Stack Exchange does not get hold of your passphrase at any time, it wouldn't even realize when you change your Google passphrase. Instead, Google sents a kind of certificate to Stack Exchange, handing over some identity information, which might just be some numeric identifier, but could also be enriched with additional information like your mail address.
There is a great image describing the workflow on Wikipedia:
"OpenIDvs.Pseudo-AuthenticationusingOAuth" by Saqibali - Own work. Licensed under CC0 via Commons.
OAuth does thing a little bit different by not passing certificates, but a kind of access key. To simulate OpenID behavior through OAuth, the identity provider would provide a simple service that can be used for only authentication. If the key "fits", the user successfully authenticated.
The whole scenario is secure, given a few security precautions.
- You shouldn't give your passphrase to a fake authentication provider looking similar to your real one (for example, a fake Google page for phising attacks). This is like providing your passport to some fake notary, that will make a copy and do bad things with it. This can be mitigated through careful verification of the site URI (password managers and automatic passphrase lookup per URI are very helpful with this!) and using additional security measures like two factor authentication.
The certificate can only be used for a given time, and is only valid per site. For example, a fake Stack Exchange web site might get hold of a certificate. But as this is only valid for the "fake Stack Exchange", the attacker will not be able to use it to authenticate against the real Stack Exchange or other websites.
The actual implementation of this differs between all of the single sign on technologies, but they all implement a similar method to bind certificates to third parties.