Choose who signs users in

Each site has an id mode: which authority a request is read under. The mode decides it, not whichever cookie the request happens to carry. Your organization has a default mode, and any site can have its own.

Mode	Who signs users in	What EdgeKit holds
edgekit_only	EdgeKit. The default.	The user and their EdgeKit session.
external_only	Your existing login	The user, created on first sight of your login’s credential. No session.
dual	Your existing login, then EdgeKit	The user, and an EdgeKit session made from your login’s credential.

external_only and dual need your login connected as an identity provider; see Connect your existing login. Together they are the path from an existing login to EdgeKit ID; see Move users off your existing login.

What each mode changes

Route or behaviour	edgekit_only	dual	external_only
Sign in with a code, a magic link or Google	Open	404 unless EdgeKit has turned it on for the site	404
GET /v1/id/get-session	The EdgeKit session	The EdgeKit session, or an exchange of your login’s credential	Your login’s credential, verified on every request
POST /v1/id/session/exchange	404	Open	404
/v1/id/user-details	Open	Open	404
/v1/id/change-identifier/*	Open	404	404
/v1/org/*	Open	Open	404
POST /v1/id/sign-out	Ends the session	Ends the session and answers your login’s logoutUrl	Clears EdgeKit’s cookies
An EdgeKit session cookie	Read	Read	Ignored
Decide knows the user from	The session	The session	Your login’s credential, on every request
external.* facts in your rules	Empty	Empty	Your login’s mapped claims

A closed route answers 404 not_found, No route matches this path., never 403, so a request cannot tell whether the route exists in another mode. GET /v1/id/config lists what a site serves in operations, and its methods is empty wherever EdgeKit sign-in is closed.

At an external_only site, an EdgeKit session is ignored

At an external_only site, EdgeKit reads the user from your login’s credential and from nothing else. A user who signed in with EdgeKit on one of your edgekit_only sites carries a session cookie that would reach a sibling site under the same cookie domain. At the external_only site that cookie never names the user, on any route or in decide. POST /v1/id/sign-out there still ends the session it carries.

The credential is checked on every request:

• A valid credential names the user. GET /v1/id/get-session answers with session.kind external, session.id null, and the credential’s own expiry.
• A missing, expired or forged credential reads as signed out: GET /v1/id/get-session answers 200 with two nulls, and decide answers as for an anonymous device. Neither refuses the request.
• Your server cannot name the user on a decide request: a userId sent to decide at such a site is refused with 422 unprocessable_entity, This site cannot take an asserted userId..

Claims from your login are facts, never grants

At an external_only site, the claims you map from your login’s credential reach your rules as external.* facts, such as external.membership_level. They are verified against your identity provider’s key, read at the attested trust level, and never stored. They are never turned into grants and never merged with grants.*: a rule that should let your login’s paying users in must read external.* itself. A missing credential means no external.* facts, so a rule waiting for one does not let the user in.

external.* exists only at external_only sites. A deploy is refused while any feature that reads external.* covers a site in another mode, and a feature with no sites listed covers every site.

Who sets the mode

EdgeKit sets your organization’s default mode and each site’s own, as part of your configuration, so a mode change reaches requests with a deploy like any other change: see Stage and deploy a change. There is no rollback: going back is another change and another deploy, as in Undo a change. EdgeKit sign-in at a dual site is turned on the same way, per site.

A deploy is refused when a site in external_only or dual has no identity provider to read, or when a site’s mode is not one of the three.

Your pages can read a site’s mode from idMode in GET /v1/id/config. That answer is cached for up to 5 minutes, so a page can show the old mode for that long after a deploy, while EdgeKit enforces the new one at once.