Security and daily use - Google, GitHub, and Facebook
Resolution order
On every provider login DockRay checks three things in order: whether a link already exists for that identifier with that provider - if so, it logs in right away; if not, whether a user exists with the returned e-mail address - if so, and the provider verifies addresses, it attaches the link to that account; if none of that, it creates a new tenant account. A link is looked up by the provider's identifier, never by e-mail - a person can change their address, but the identifier never changes.
Not every provider verifies the address
Attaching a login to an existing account by e-mail is allowed only for a provider that genuinely verifies addresses. Google and GitHub do - GitHub returns the account's primary address. Facebook does not: its documentation does not guarantee this, and an address can be entered into a profile with no proof of access to that mailbox. If DockRay attached logins by Facebook e-mail anyway, creating a profile there with someone else's address would be enough to walk into their account. That is why a Facebook login that lands on an existing address ends with a message asking to sign in with a password instead of silently attaching - and a new account created this way goes through the ordinary e-mail verification, since the address is not confirmed yet.
What an account created this way gets
The password of an account created by social login is random and never handed to anyone - the way to a real password runs through a reset, meaning the same mailbox. The e-mail address is confirmed immediately if the provider verifies addresses (Google, GitHub); logging in with such a provider also confirms the address for someone who registered through the form and never clicked the verification link.
Social login and the second factor
If an account has two-factor verification switched on, a provider login does not bypass it - after returning from Google, GitHub or Facebook, DockRay asks for the second factor exactly as it would after a password login. The provider proves identity; whether that identity gets into the panel is decided by DockRay alone.
A deactivated user and rotating keys
A deactivated account cannot log in this way, no matter how correctly the provider confirmed the identity - account status is checked regardless of the login method. If you suspect a provider's Client Secret has leaked, generate a new one in its developer console and paste it into the platform settings - existing account links are unaffected, since they are tied to the user's identifier at the provider, not to the application secret itself.