That's the programming, config, testing stuff (for the OAuth service) more or less done. There are a couple more things I could do (mostly about pulling in client info onto the consent screen to make it much more "Example.com wants access to...", but that's not MVP, at least at this (tiny) scale.

What I need to do next is decide where it all goes administratively. Is it part of webmail (or something like my blog), or is it a stand alone service?

I'm leaning towards webmail. It's already got the login/user infrastructure (and accounts), and name recognition with the expected userbase (me and husband), I'm just reluctant to mess with it while it's working. I guess that's what branches are for.

Plan

Hang it all off the webmail domain. Webmail users shouldn't notice anything different. I'll need to tweak the paths a little too make sure that nothing overlaps, although the existence of a challenge query parameter is diagnostic of an OAuth request.

I'll need to do a migration on the webmail db, no worries, I need to get a backup/restore thing working anyway.

I'll end up with a "new client" script, the settings will all be more or less the same each time, only the name changes (and at that point I can integrate it with the new user/project script)

Scary, but doable.

The testing setup I had working for webmail (running dovecot in s container) has stopped working and I don't know why :-(.

I mean, it's clearly something to do with container networking but I haven't been name to chase it down properly. Roughly, dovecot auth should be hitting an http endpoint to validate the given username and password, but I don't think the http request is making it out of the container.

My next step is probably too break out tcpdump to see if I can trace the packets, but I want to understand how podman does it's networking first. (Specifically, I want to know how it's getting packets out of the container without an interface).