🏴 Authentication (/ authorization ?) provider for authenticated, present and future, Warta-services.
🇫🇷 Fournisseur d'authentification (/ autorisation ?) pour les Warta-services présents et futurs nécessitant une authentification.
- Practical front-ends: HTTP and Discord bot
- High-level protocols: OAuth2, OIDC, JWT
- Main tech stack:
rocket
,diesel
,ructe
andserenity
(inspired by Plume, go check it out btw) - Other noteworthy external stuff depended on:
xp.css
,postgresql
Variables:
# Both
DISCORD_KEY_FILE=discord_jwt.key
HTTP_BASE_URL=http://localhost:8000/
# Discord bot
DISCORD_TOKEN=...
DISCORD_ALLOWED_GUILDS=012345678901234567
# Server
#DATABASE_URL=postgres://username:password@localhost/wartid
# This is currently set in Rocket.toml
Both of the binaries can (and will) load .env
files in their CWD.
cd wartid-server
cargo run --manifest-path ../wartid-server-discord-bot/Cargo.toml &
cargo run --features discord-bot
- User passwords are stored and validated with bcrypt
- OAuth2 secrets are stored in plain text (they need to be displayable)
- We could store them as a tagged union that allow the developper to "hide" it after copying it:
Disabled | Plain(password) | Hidden(bcrypted_password)
- We could store them as a tagged union that allow the developper to "hide" it after copying it:
./discord_jwt.key
is extremely sensitive, it contains the key used to forge the Json Web Tokens for discord-based login (and account creation).wartid-server
SHOULD delete it on SIGINT.- It would be safer to directly communicate the key between
wartid-server
andwartid-server-discord-bot
, although more complex to set up on each machine, especially if one of the processes need to be restarted
- It would be safer to directly communicate the key between