Building a member area on Core dna: who a member is in the data, the sign-in flows and their templates, single sign-on and passkeys, the my-account routing convention, members-only content, sessions and the page cache, and the security checks to run before launch.
L2
Unit 03 · Authenticators, SSO and linked accounts
How the sign-in methods fit together
Authenticators, SSO and linked accountsPage 15 of 36Updated
A member can sign in with a password, a passkey, or an outside provider such as Google, Microsoft or Facebook, and one account can hold several. The model behind that, the methods that are checked locally, every provider the platform ships, which are safe to enable, and the policy questions to settle with the client.
Who this is for. The developer adding single sign-on to a member site, and whoever agrees its rules with the client. Afterwards you can say which sign-in methods a member has, what each needs, and what happens when one is removed or switched off.
The model
Two things are easy to confuse, and the rest of this unit depends on keeping them apart:
An authenticator is a way of signing in that the platform supports: local (a password), passkey, google, microsoft, facebook and coredna. It is switched on or off for the whole site in the settings.
A user authenticator is a link between one user and one authenticator: "this member may sign in with Google, as this Google account". A user has at most one link per authenticator, and may have several links.
A member, Sam, with three links
What the link holds
local
Nothing beyond the fact: Sam's password is on Sam's user
google
The Google account's id, and a refresh token Google issued
passkey
Sam's registered passkeys, one per device
Sam can sign in with any of the three. Each link records when it was created and last changed. A sign-in through a method succeeds only when the method is enabled for the site and Sam has a link to it.
Methods checked by the site itself
A password and a passkey are checked by the site, with nothing outside involved; the platform calls them first-party. A password link is created whenever a password is set: at registration, through a reset, or by adding one on the linked-accounts screen. Removing the password link deletes the stored password too, so it cannot come back when password sign-in is added again later.
Local and outside methods sit side by side on one account. A member who registered with a password can add Google; a member who arrived through Google can add a password or a passkey. Password sign-in can also be switched off for the whole site, with the Local Password setting Enable, leaving members only providers and passkeys.
The providers
The platform ships four outside providers. There is no generic OpenID Connect or SAML provider: a site cannot add another.
Provider
Needs, in the OAuth settings
Asks the person for
Usually used for
Google (google)
Client ID and Client secret from a Google Cloud OAuth client
Email address and basic profile
Customers, and staff on Google Workspace
Microsoft (microsoft)
Client ID, Client secret and Tenant, from a Microsoft Entra ID app registration
Basic profile
Staff and partners of organisations on Microsoft 365
Facebook (facebook)
Client ID and Client secret: the Facebook app's id and secret
Email address and public profile
Customers
Core dna (coredna)
Nothing: the platform configures it
A Core dna staff sign-in
Core dna's own staff, supporting the site
Google, Microsoft and Facebook are off until enabled. The Core dna provider is on by default and appears among the providers the sign-in page lists, so leave it off member-facing pages (Sign-in buttons). Google, Microsoft and Facebook each also have Forbid Backend Login, which stops it being used to sign in to the admin. Enabling a provider walks through the setup.
Which providers are safe to enable
When someone signs in through a provider, the platform finds their account by the email address the provider reports. Enabling a provider therefore means trusting it to report only addresses its users really own (Matching a provider sign-in to a member). In practice:
Enable only providers whose addresses you trust for the audience: one provider per audience is easier to reason about than all of them.
For Microsoft, set Tenant to the organisation's domain or tenant id whenever the site is for one organisation's staff or partners. With the default, common, anyone with any Microsoft account can sign in.
Keep password sign-in as a way back in for members, unless the client has a reason not to.
Policy questions for the client
Settle these before launch. The platform decides some of them; the others are the client's choice, with a consequence either way:
Question
What the platform does
Consequence
Can a member remove their last way in?
No. The last link is refused with "At least one category one user authenticator must be enabled"
The count includes links to providers the site has since switched off, so a member can still be left with no method that works
Can a member who signs in only with a provider set a password?
Yes, through the forgotten-password flow or on the linked-accounts screen, while password sign-in is on for the site
If the client wants provider-only accounts, switch password sign-in off for the site; otherwise tell such members they can add one
What if a provider is switched off later?
Its buttons and callback answer 404; a member's existing link to it is kept, but does not sign them in while the provider is off
Members whose only link was that provider get in again through the forgotten-password flow, which needs password sign-in on and an active account with their email address. Announce a withdrawal before it happens
Can members remove the Core dna link?
No; only an administrator can
Matters only for staff accounts, which should not be member accounts anyway
Passkeys for accounts linked to Core dna?
Refused: those accounts manage passkeys on their Core dna account
None for members
Where the client wants staff to use only their organisation's sign-in, combine a restricted Microsoft tenant with Forbid Backend Login on the other methods.