I designed a custom authentication protocol for Atomic Data. It's a simple system, and it gives people a great amount of control over their online identities, but it has limitations:
It's a custom system. Developers will need to deal with this, and they don't like to spend time on a problem that has already been solved with tools that they are familiar with.
Signing things is more complicated than storing a single token. Although signing is far more secure, of course, some may want to simply pass a static token in an HTTP header - it is easier to use. This is relevant in many contexts, such as CI, CLI apps (e.g. curl) and more.
So how should tokens work? Let's consider a few approaches:
OpenID Connect, OAuth, JWT
The standard stack for authentication, used everywhere.
Doesn't give the user the same amount of control over their identity as Atomic Auth does.
Just JWT + /getToken Endpoint
User sends an authenticated HTTP request to /getToken.
Server responds with a token, which is valid for some time (maybe later add an optional expiration query param). This token should probably be a JWT.
This token can then be sent using an HTTP header like so:Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ
Provides a decent GUI to create new tokens, without too much work.
Uses Atomc Endpoints, which is the way to go
Still not compatible with OAuth / OIDC
Client-side signed tokens
Client signs an Authentication, similar to how websocket auth currently works in Atomic Data.
This signed Authentication should also include an expiration date and a server, not a subject
We can set the Authentication as a cookie and include it in all following requests
Considerations:
Signature has to be set only once per session / day, instead of for every single request. Since signing something could take up to a few milliseconds on slower devices, that could make the app more performant.
We could pass the token in all requests using a cookie, which means we can use this authentication mechanism also for downloading images (we can't manually set headers when browsers automatically fetch images)
Since we only sign once per session, the client only needs access to the private key once! This Means we can probably use the web.crytpo library to sign the cookie.
I designed a custom authentication protocol for Atomic Data. It's a simple system, and it gives people a great amount of control over their online identities, but it has limitations:
So how should tokens work? Let's consider a few approaches:
OpenID Connect, OAuth, JWT
The standard stack for authentication, used everywhere.
Just JWT +
/getToken
Endpoint/getToken
.token
, which is valid for some time (maybe later add an optional expiration query param). This token should probably be a JWT.Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ
Client-side signed tokens
Considerations:
web.crytpo
library to sign the cookie.