A stolen login stops working

What actually happens

Three things, in order. You only write code for the middle one.

1. 1

   Someone signs in

   Your existing login stays exactly as it is. TokenForge does not replace it and never sees a password.

2. 2

   Their device gets a key

   The browser creates a key that cannot be copied out of it — not by a script, not by an extension, not by you.

3. 3

   Every request proves the device

   Requests carry a signature from that key. A stolen session copied to another machine cannot produce it, so it stops working.

Pick how you want to add it

All three end up in the same place. They differ only in how much of your app you have to touch.

• No code

  Point your domain at us

  You can change a DNS record.

  Add one record and we handle the rest — the browser piece is inserted for you and every request is checked. Nothing in your app changes.

  Set this up
• Two small pieces

  Add it to your app

  You have a web app and someone who can edit it.

  One call in the browser, one route on your server. This is the usual choice, and it works with whatever you already use to sign people in.

  Walk me through it
• For engineers

  Server frameworks and apps

  You want the exact code for your stack.

  Ready-made setup for common server frameworks, plus phone apps and automated agents. Same protection, native to each platform.

  See the code

Questions people ask first

Do my users have to do anything?

No. Nothing changes for them — no extra prompt, no new app to install, nothing to remember. The device sorts itself out in the background the first time they sign in.

Does this replace how people sign in?

No. Whatever you use today — Google, Microsoft, Okta, your own accounts — keeps working exactly as it does. TokenForge runs alongside it and never sees a password.

What if TokenForge goes down?

Your users keep working. Registering a device adds protection on top of your login; it is not a gate in front of it, so an outage on our side does not lock anyone out.