I've been researching more about different ways that authentication is handled. I am especially drawn to stateless tokens, since they don't required any management by the server.

The most prominent stateless token solution is JWT (JSON Web Tokens). While I like the stateless nature, I find it ironic that *JavaScript* object notation was chosen as the encoding format for a token that can't be modified or created by the client side. Perhaps the point is that the client can easily *read* the token information.

Follow

I'm also aware of the BARE encoding, which could be used to make a much smaller and simpler token format - drewdevault.com/2020/06/21/BAR

Here's the problem/caveat I have with any standardized format:
Assuming I don't really care about letting the client read the metadata in the token, the only program creating and using these tokens is the server, which means all that matters is whether the server is consistent with itself. That is, standardizing the token format is not important when token contents are not intended to be public (and why should they be?)

Thus, I am inclined to use the most convenient binary encoding/decoding format that my language provides (like the haskell "binary" package).

Note that I am not saying BARE is pointless, since not everything message is a token. However, it does seem to me that the motivating example in the blog post is does not compel the use of a *standardized* format (although it does a good job of advocating a *small* format).

Sign in to participate in the conversation
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!