OAuth covers two jobs that are easy to confuse: letting other applications act on your site, and letting people sign in with an account from elsewhere.
Two jobs, one module
Applications acting on your site. Every Core dna site is also an OAuth server. A mobile app, an integration or a partner's system is registered as a client and gets access through the API, for itself or on behalf of a member who agrees.
People signing in with an outside account. A member signs in with Google, Microsoft, Facebook or a Core dna account instead of, or as well as, a password or a passkey.
OAuth clients
A client is a registered application, managed in the admin's OAuth Clients list. Each has a name, a client ID and secret, the grant types it may use, the redirect URLs it may send a person back to after they approve, the scopes it may ask for, and whether it is confidential (able to keep a secret, like a server) or public (like an app on a phone).
OAuth is the preferred way for an integration to authenticate with the API; API keys are the older option.
Regenerating a secret
A client's secret can be regenerated from its record, for example when it may have been exposed. The new secret replaces the old one at once, so the application stops working until it is given the new one: plan the change with whoever runs it.
Consent
When an application asks to act for a member, the member sees what it wants and agrees or refuses. The agreement is recorded with the scope granted and the date. Members can review these under authorised applications in the account area and withdraw one; the application then loses access straight away and must ask again.
Signing in with an outside account
Each sign-in method (password, passkey, Google, Microsoft, Facebook and Core dna) is switched on or off for the whole site in the OAuth settings, where the outside providers also take their client IDs and secrets. A member can link several methods to one account, at most one of each, and manages them under linked accounts. Password sign-in can be switched off for a whole site, leaving outside providers and passkeys. There is no generic OpenID Connect or SAML provider. Single Sign On (SSO) covers the set-up.