search

triceratops-project / triceratops

1 stars 0 forks source link

Authentication Rewrite #1

Open FelixKLG opened 9 months ago

FelixKLG commented 9 months ago

Reconfigure how clients authenticate with the panel to prevent access to the application API using client tokens. To prevent token grabbing exploits and abuse of API endpoints.

There will be a separate section for site administrators to configure usage of the API and permit or deny client access to the API.

Prob cookies & JWTs EC256 or some other alg; depends on what I wanna put in the config.

FelixKLG commented 9 months ago

I recommend using JWTs to contain some basic user info but keep the session information in Redis on the server. This would require a way to store it in the client, optimally cookies. Axum extra's cookie jar is kinda shit and requires it to be sent back in the response type which I strongly dislike, that shouldn't work like that; hopefully there's a better way around that.

I'd suggest looking into this crate for cookies: https://crates.io/crates/tower-cookies (check it's code for mutexes/RwLocks and stuff, we don't want too many of those)

The sessions should expire after a set duration, not be valid before a certain duration. yada yada yada standard JWT shit, try use either EC256 or some kind of symmetric system, depending on how well it goes into the config.toml file. The config file is large as it is already, try not to make it explode) Also think about how easy it is to deploy the server, it shouldn't be horrendously complicated.

If you wanna make an EC256 keypair that works with JWTs you can use the just command generate-keypair. It's still there from my testing as of a0a7fd661634ffb18ab464cb9406cafc5bc722ca.

FelixKLG commented 8 months ago

So was thinking about this recently, I want to use a hybrid solution of stateless and stateful, the JWT will be the primary authentication method and store all the information however there will also be a session ID attached to it. That session ID will be stored in Redis (KeyDB) where it can be remotely revoked and also have additional information appended to it such as CSRF and PKCE codes in the case of OAuth.

That being said I also want to rejig sessions hopefully to not be entwined to authentication, in the case of Laravel every person that visits the site gets a session but that doesn't strictly mean that they are signed in. This way of handling sessions allows you to affix server-side information to site visitors uniquely (instead of via IP) without them needing to sign in. This wouldn't be too hard to do as I can do most of it within Tower's layer trait but it would require some existing code to be rewritten but Triceratops is still in infancy. There would also need to be some thought into how to ergonomically make something like this in Rust.