so like, all the staff at the kids' school have google-workspace-managed gmail addresses at the school's domain name. i can tell haproxy to let them "sign in with google" (oauth2) and thereafter they may access staff-only pages without maintaining any database or user list on my server

i can configure haproxy to do the denying, or have it set the visitor's email address into the headers that get proxied back to the webserver. no need for the webserver to know how to oauth

this counts as december adventure

with a short python cgi script i'm close to having oauth2 working
(via google first, then more)

oauth2 gives a signed jwt
haproxy can validate and pull data out of that for use as acl material

this means i can say "only people who have a google workspace account at the kids' school may request these urls from my static site"

or

"only my local fedi tl may post changes to this wiki"

with no server side database or redis or anything 😎

if it works

december adventuring

work in wip progress: i have a short python cgi that implements enough of OIDC (Open ID Connect, based on OAuth2) that you can click a link on my site to "sign in with google"

i receive what you told google your name and email address is, signed by google

i stick that into your browser cookies so i don't have to store it

next step: get haproxy to parse and verify it to let you see the secret pages, if i like you

maybe replace with my own, shorter, signed cookie

oh my gosh i am logged in -- securely attesting my identity to my mostly static website! the only moving parts on my vps are a little script that stuffs the key into a cookie and some configuration in haproxy to make it inspect and verify it

the list of allowed users amounts to a text file, no database or session storage on the server. all i will have to do to "give you an account" so that you can access the secrets and writeable parts is put your google email address in a text file

next steps:

• as is, this doesn't let google track you as you click around my site. it only knows you granted permission to my site to see your name and e-mail. but i want to expand this to work on any oidc provider that i decide to trust including your or my jank homebrew ones because fuck google

• stuffing the whole signed jwt into a cookie is kinda heavy. will probably replace that with my own smaller one that doesn't encode anything i don't need to control access

why don't more sites do it like this? i think because

• wow oauth and oidc are tedious
• google and facebook and apple and microsoft and auth0 by okta would all prefer that you use code that they control, or pay for their service instead of rolling your own
• why would you go to the effort to avoid storing session data on your server when you have this huge database right here to collect as much customer info as possible to sell to the highest bidder

yay i'm gonna implement an OpenID Connect client so you can log into my website with any of the many OpenID Connect Providers out there and i don't have to keep a list of usernames and passwords!

except i hate google, reddit, github, twitter, facebook, amazon, paypal, and apple so,

you can log into my website with your existing account on...
salesforce,
auth0, or
yahoo

so convenient! ✨

back to the tech wip: currently figuring out how to use the state parameter to stop csrf attacks, without storing stuff on the backend to verify it hasn't changed, also without accidentally inviting tampering and replay attacks

i think i can just stick a random number in there, "sign" it with an hmac, store the hmac in cookies, check that against state when it comes back

"don't roll your own crypto" but ya'll didn't roll it for me so guess what

(cue ridin' by chamillionaire)

december adventure, wip:

• learned about blake2, used it for the signed state parameter, seems to work well
• got the secrets out of my script so i can commit it to version control and share it
• got a couple of the possible error messages to be less ugly
• tightened up the security params of the cookies i'm using
• deleted the state cookie as soon as we're done using it

to do:

• use a small signed data blob in cookies not the big id token google hands us
• tidy up my use of pyjwt
• stop hardcoding, and instead properly cache, and refresh, oidc discovery documents and providers' certs
• see how hard it is to enable more oidc providers than google (ideally just, register with them and add their discovery document url?)
• something neat on the frontend so you can actually tell that this stuff is working 😅
• blog about it

i must be getting deep into it, just learned that this issue i'm struggling with is not my own fuckup, it's a bug in haproxy that's causing responses to fail in glitchy ways when a jwt signature doesn't validate

haproxy devs know about it and fixed it but the patch hasn't been backported to various versions yet

https://github.com/haproxy/haproxy/commit/46b1fec0e9a6afe2c12fd4dff7c8a0d788aa6dd4

my workaround for now is going to be only attempt jwt validation when the keys match

random achievement: got my travel router set up as a proper travel router

updated openwrt, installed travelmate. now my partner and i can use our phones and laptops together on the hotel wireless without paying exorbitant additional-device fees (not that we ever did that) and have high-quality file transfers between our own devices

there's not enough room on it to install tailscale so maybe it's time to more seriously consider zerotier or a manual wireguard setup

my workaround for the haproxy issue upthread 🧵☝️ doesn't work great because google and probably other identity providers rotate their certificates frequently

instead of building a giant contraption to keep haproxy config updated with multiple configuration lines for every cert i might need, i'm trying to do what people used to do before haproxy grew a jwt_verify builtin: do it with a lua plugin 😎

part of me gets excited about it like  what other clever hacks could i do with a lil lua plugin to haproxy!

openresty pretty famously implements an entire web platform in what was probably intended to be a little lua extension for nginx

then on top of that web frameworks like lapis exist which let you code your web thing in lua, moonscript (kinda coffeescriptish) or fennel (lisp!)

https://openresty.org/en/
https://leafo.net/lapis/
https://fennel-lang.org/

a high quality mufo recently mentioned caddy so i looked and gosh

caddy (w/plugins) has a lot of things i stalled out trying to make happen with haproxy+lua+lighttpd:

• jwt, oidc, client cert auth
• webdav
• fastcgi
• dispatch by sni
• a static fileserver
• precompressed files
• if-unmodified-since (with PUT?)

but i agree that the glossy marketing website is sus. some exec is going to spring a trap as soon as it's popular

caddy is golang which i've been stubbornly avoiding learning for as long as it has existed. i would prefer software that stands between my computer and the nasty internet to be written in rust...

but, as much as i dislike golang i think i dislike c and c++ even more

haproxy and nginx are both written in c, and i've segfaulted both with mere configuration file mistakes which makes me super nervous

so maybe i will try caddy next