The death of replit identity

I’m making this post since I’ve seen a lot of people saying replit identity is broken and/or doesn’t work, and I’ve decided to document how that happened and why it’s safe.

Replit identity

Replit identity is a solution for zero-click auth (like replit auth, but without login) for console applications on replit and secure communication between repls, and for that, it works very well.

The Misunderstanding

While replit identity was marketed as Zero-Click Auth For Your Apps, the leading example for it’s usage was:

Picture this: you’ve built an arcade game on Replit. Gamers playing your game will head to the repl’s cover page and click “Run”. They love your game, and they send you feature requests and ideas in the comments. Now, you want to keep track of high scores and add other social features to your game. This used to be a show-stopper: there was no way to verify the API requests coming in, so your high-score feature was either easy to spoof, or simply didn’t get off the ground.

We’re rolling out Repl Identity to solve this.

While there is nothing wrong with this example, it was severely misunderstood and people thought that if you send a request with an identity token, somehow the information in the request’s body was 100% safe, but it wasn’t, so when a few repls using the technology in a wrong way got “hacked”, everyone thought it was unsafe.

Proper usage

Replit identity should only be used to authenticate the user accessing your server for example, you should never trust any information the client is sending to your server.


You have a game in which you want to create a leaderboard storing high-scores, you should calculate, store and keep track of the high scores on your server, and use replit identity to verify who made the high score.

By the way, I made a simple npm package which lets you use it, example repl is here.

I’ve updated the example to use a server.

I get a SyntaxError when I run the Repl.

SyntaxError: Failed to parse JSON

Hey, that’s because server repl was sleeping, I’ve updated the code to handle that as well.

Actually, I think people thought it was unsafe because before Replit’s console changed to this thing with the “sessions”, it was trivial to just run replit identity create in your ghost fork and generate a completely valid identity token that could be used to spoof requests.

It’s harder to do that now of course, but there still might be a way


I decided to omit this part intentionally, because spoofing a request doesn’t make it vulnerable.
The good part about replit identity is that you can’t impersonate anyone no matter what you do, so it proves the identity of the user visiting your repl.

Sidenote: spoofing requests was possible even before the cli tool :shushing_face:

True. I didn’t notice that you said

in your original post.

There was a version of replit identity before the cli tool?


Wait I don’t get it - what is replit identity? The blog post left me with more questions than answers.


Replit identity is basically having…

  1. A secret key for the server to generate public keys, and…
  2. a piece of data (lets call it the public key, referring to SSL/TLS certs) given to the client which can only be generated on the server by using the secret key with a one-way mathematical function (such as the remainder/mod function). This piece of data has a username stored in it, which technically can be arbitrary data.
  3. The server checking if the piece of data was generated with its secret key

BTW Feel free to ask clarification/follow-up questions!

1 Like

How does it ‘authenticate’ the user?
(Gosh, I really need an example)

1 Like

Hey, well, the simplest explanation would be that when you run a repl someone else has made like my example it can “encrypt” your name and some data about the repl in a string, then it can send that string to a server, where your data will be “decrypted” and the server will know who you are, so you are authenticated.


The token isn’t information you trust as well, libraries for replit identity and the cli tools are full of tests to check every part of the token is valid, you just don’t see all of that because a simple interface was given to you. You’d have known if you read the how do I use it part of the article I’ve linked.

Yes, there was, again the article I’ve linked to is before the creation of identity cli tool, it came 6 months after.


Why not? If the token was signed by replit’s public key, I don’t see any reason not to trust it. (unless you’re saying that you shouldn’t trust it without verifying it first)

1 Like

correction, its private key. You can get public keys using a private key, not the other way around. If its signed by a private key, then you should be good to go (as long as you trust the private key which in this case is Replit)


Yeah, I meant as long as you can verify it with the public key

Yeah, that’s what I meant, you don’t trust it by default, the libraries do many checks to see if it’s vaild before responding to you with the “trusted” information.


Kinda strange the cli tool doesn’t work in deployments yet.


You probably can’t expect replit to have upkeep and support of mission-critical apps, so idk what they’re trying to do here… but I wonder, do deployments run on nix?

Replit Identity is for command-line apps and Deployments are for web apps, right? I don’t see why it needs to work on Deployments in that case. Use ReplAuth for web apps. Or did I miss something?