EdgeKit ID FAQ

Does EdgeKit ID use passwords?

No. A user proves they hold their email address each time, with a 6-digit code or a sign-in link emailed to them, or signs in with Google. EdgeKit never stores a password, and there is no password to reset.

Which social sign-ins can users use?

Google only. It uses your organization’s own Google OAuth client, so users see your consent screen, not EdgeKit’s. There is no Apple, Facebook or other social sign-in.

Does EdgeKit host a sign-in page?

No. Your pages draw the sign-in form, the code field and the preferences form, and call EdgeKit for each step. EdgeKit sends the emails and holds the session. See Sign users in.

Can we change the wording of the sign-in emails?

No. The code and link emails have fixed wording. Your organization’s transactional mail settings set the sender name and address they come from; see Site settings.

Does signing in on one site sign the user in on our other sites?

Only on the sites the session cookie reaches. The cookie belongs to the host the user signed in on, or to your organization’s cookie domain when EdgeKit has set one, such as example.com for www.example.com and shop.example.com. On a site under another domain the user signs in again, with the same address, and is the same user with the same grants. See Sessions across your sites.

Can the same person have separate accounts on two of our sites?

No. Your organization has one user per person, and no two users share an email address. A site records that a user has been seen there; it never splits them into a second user.

How long does a session last?

30 days from when it was last extended, and reading the session extends it, at most once a day. A user who comes back at least once a month stays signed in. See How long a session lasts.

Can a user sign out of every device at once?

Not with one sign-out: POST /v1/id/sign-out ends the session of the browser or app that sends it. Every session ends when the user changes their email address. If your organization uses its own login, your server can end every EdgeKit session a user holds with POST /v1/id/upstream/revoke-sessions; see Tell EdgeKit about changes in your login.

Can we keep our existing login?

Yes. At an external_only site EdgeKit reads your login’s credential on every request and never signs anyone in itself. At a dual site your login still signs users in and EdgeKit takes over their sessions. See Choose who signs users in and Connect your existing login.

Do our users have to sign in again when we move to EdgeKit ID?

Not while a site is dual. A user signed in to your login gets an EdgeKit session the first time a page there reads their session, with no form to fill in, and keeps it. A user who first comes back after the site moves to edgekit_only signs in once with EdgeKit ID, by email, and gets the user they already had. See Move users off your existing login.

Do we have to export our users’ passwords?

No. EdgeKit never reads a password from your login. It reads the credential your login gives a signed-in user, and creates or finds each user the first time it sees them.

Does EdgeKit sign users in through our login with OpenID Connect or SAML?

No. EdgeKit does not redirect users to your login and back. It accepts a token your login signs, or asks your login’s session endpoint who holds a cookie. See How EdgeKit verifies it.

With HS256, can EdgeKit sign in as one of our users?

Yes, in principle. With HS256 you and EdgeKit hold the same signing secret, and anyone holding it can sign a credential your sites accept. With RS256 or ES256 EdgeKit holds only your public key and cannot.

What happens if our login says an address is verified when it is not?

EdgeKit believes it. A credential with email_verified: true for an address that already has a user is linked to that user, who keeps their grants, so the person holding the credential gets them. Nothing marks it as unusual. Only assert email_verified for addresses your login has proven.

Does EdgeKit ID work in our mobile app?

Yes. A native app signs in through the same routes and receives the session as a token in the set-auth-token response header, then sends it as Authorization: Bearer. See Native apps.

Can page scripts read the session?

Not the cookie: it is HttpOnly, and the browser client never handles a session token. A sign-in response also carries the token in its set-auth-token header, for native apps. A page on another origin cannot read that header or send Authorization. A script on your own domain calling /edgekit/ is same-origin, so it can read the header when your forwarder passes it through.

Is there two-factor authentication or passkey sign-in?

No. EdgeKit ID offers the email code, the magic link and Google, and nothing else. If your login asks for a second factor, keep your sites on your login, in external_only or dual with EdgeKit sign-in left closed.

Does sending a code tell anyone whether an account exists?

No. Sending a code or a link answers 200 whether or not a user holds the address, and so does asking to change an address to one another user holds. Only the final step of an address change says the address is taken, and Google sign-in says so to someone holding a Google account for an address whose user is not verified yet.

Does EdgeKit check a captcha?

No. GET /v1/id/config can name a captcha widget and site key for your page to show, but no sign-in route checks a captcha answer. What EdgeKit enforces is its limit per address: 3 sign-in emails and 3 code attempts a minute.

Can we switch magic links off for one site?

Not on the routes. The magic-link routes answer wherever EdgeKit sign-in is open, whatever a site’s methods say. The methods change only what GET /v1/id/config offers, so your page can leave the button out. While magic link is in any site’s methods, no trait can be required. A magic link cannot be completed today anyway; see Sign in with a magic link.

Can a user change their own email address?

Yes, at an edgekit_only site: they confirm a code sent to the new address, and every session they hold ends. At a dual or external_only site your login owns the address, and your server tells EdgeKit about a change. See Change the user’s email address.