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 02 · Registration, sign-in and password recovery
One-click sign-in links
Registration, sign-in and password recoveryPage 12 of 36Updated
A sign-in token is a link that signs one member in, a limited number of times, until it expires: the mechanism behind the password reset email, and available for campaign and re-engagement emails. How tokens are made, what the link does, when to use one, and the limits that keep it safe.
Who this is for. The integrations engineer asked for "a link that logs the member straight in" from an email, and the reviewer deciding whether that is acceptable. Afterwards you can issue such links with limits that make them no riskier than the reset email every site already sends.
The token
A sign-in token belongs to one user and carries its own limits:
Field
Means
user
The user it signs in as
maxUses
How many times the link works
expires
When it stops working
expireTimeAfterUse
Seconds it keeps working after its first use, if that is sooner
redirectUrl
Where the member lands after signing in
The platform makes one itself for every password reset: two days, ten uses, an hour after the first (The link). For any other purpose, an integration makes one through the API. Only an administrator's credential may: the route refuses every other user. Templates cannot create tokens.
HTTPCreating a token for a campaign email, from your server
The answer holds the new token under data.loginToken (Create a login token). Build the link from it, /token-login?t=<token>, put it in that member's email, and keep the token nowhere else.
What the link does
/token-login checks the token, counts the use, signs the member in with a full session (twelve hours, like any sign-in) and redirects to the token's redirectUrl. Only the URL's path, query and fragment are used, so the link always lands on the same site. Without a redirect URL, the member lands where any sign-in lands (Where the member lands).
A link that fails sends the visitor to /login with a message:
Case
Message
No token in the link
"Could not login using token: Token missing"
An unknown token, or one for an account that is not active
"Could not login using token: The token could not be found"
Expired, or every use spent
"Could not login using token: The token has expired"
Make the landing page useful to someone who arrives signed out after a failed link: the sign-in page with the email's purpose in a sentence ("Sign in to see your tickets") recovers most of them.
A token can also be sent on any URL as ?loginToken=…, which acts as the member for that one request without starting a session, and spends a use each time. That suits a script, not an email: use /token-login for links people click.
When to use one
Sign-in links suit an email whose whole point is one action in the member's account: "your tickets are ready", "renew your membership", "finish your application", a re-engagement email to members who have not signed in for a year. Every click that would otherwise end at a sign-in form, with a forgotten password behind it, becomes a visit.
They are widely thought insecure. A link that signs someone in is a credential, but so is the password reset email every site sends, which is built on the same tokens. What makes either acceptable is its limits.
The limits that keep it safe
One use. Set maxUses to 1. A forwarded email then works for whoever clicks first, once.
A short life. An expiry measured in days, matched to the campaign, and an expireTimeAfterUse of minutes.
One member per token, sent only to that member's own address. Never a token in a bulk email that several people receive, a shared link, or a URL on a page.
Land on the action, not the keys. Point redirectUrl at the page the email is about. Changing the password still needs the current one, so a link cannot be turned into a takeover by itself (Why the current password is required).
Members only. Do not issue sign-in links for backend users.
Never log or store the link outside the email, including in the job or integration that sends it (Jobs).