Authz In allyabase

If you've never worked with asymmetric cryptography before, don't be intimidated! The hard stuff is done by professionals, and audited by professionals, so that us mortals are left with something to use. Here is how it works.

At the heart of auth in a system like allyabase are public/private cryptographic keypairs. Naming things is hard, but here public and private are actually well-named. Public keys can be sent anywhere. That is they are not meant to be hidden. Private keys are meant to be kept private. There's a lot of nuance to this latter point, which is covered in How Sessionless Keeps Keys Private, so we'll skip that here.

When you want to join a system that accepts Sessionless keys such as an allyabase base, you need to send the backend your public key. Client applications will then sign messages to authorize the calls with that backend.

Messages are strings, which are hashed before being signed. Right now Sessionless uses the Keccak256 hashing algorithm, but adding another like sha256 is pretty trivial. The strings are concatenations of various properties the API call cares about. At their minimum it is usually the timestamp+uuid tuple for a user, but for more important calls more information is added to the message.

Since the messages are specific to the API call, right now the best source for checking them is the code. In general the client SDKs should handle the message signing for you though.