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.
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.
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
A secret key for the server to generate public keys, and…
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.
The server checking if the piece of data was generated with its secret key
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.
There was a version of replit identity before the cli tool?
Yes, there was, again the article I’ve linked to is before the creation of identity cli tool, it came 6 months after.
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)