Nope. People use what works for them.

auth as in authorisation? not as in signin? https://authzed.com/ there is this which you may find useful. they have a open source DB if you want to do self hosting (i haven't really looked into this though).

auth as in authentication, and enough to have the user account - preferably with role information

roles are authorization. they don't magically work just cus you have code that does logging in. authorization is much harder to do than login, and it's not really a solved problem from what I've read. in my current project Auth is done with a bunch of interceptors that handle cookies, resources defs, user state, at the minimum. Auth failure also involves a lot of consideration and code. you mentioned making user accounts. I think at that point you are using a framework that already is heavily integrated into your system. not just something that you can easily plug in to your existing system. something like Django or rails. I haven't seen something like this in clojure, though ew clojure web frameworks aren't really something I pay too much attention to, so maybe there is something rail like out there.

I'm talking about a successor to friend or buddy that has all api hooks for both auth and authz, and preferably implements the hooks for oauth2 flow, or a clojure API to auth0 or any of those systems. It looks like buddy is the best shop in town

and I'm only talking about the user/role assignment info coming back in the auth response, as is typical in oauth systems, such that the app can implement the authz enforcement

ie role to permission assignment/enforcement, which obviously the identity provider isn't going to have... but may have user/group or group name or other things that can represent the role and get included in the token

i don't see oauth in buddy. however buddy's tutorials seem very nice.

(get m k identity) is consistently last place to the earlier trials, typically 1.3X slower than pre-assigned identity.

Oh well

I mostly just found it really interesting that the overhead of the simplest possible function call is roughly equivalent to, yet consistently a slightly slower than a conditional. Even though I expect my usage to be potentially "hot", the race definitely looks plenty close enough for me to favor identity until it actually proves to be a meaningful bottleneck (since it seems cleaner for my use case).

Is your keyset dynamic? Otherwise a defrecord might be faster

Good point. Actually, the plan already was leaning heavily toward use of records. So now, I just realized I should rerun those tests using a record (with a possibly nil field) instead of a map. I predict roughly equivalent results, in which case the named Record field makes choosing identity even more appropriate, unless if somehow proves wildly faster.

Surprising results when comparing records to maps on the same test conditions. For starters, the record tests results are much less consistent, and prone to a lot more randomly slow outliers. Then when roughly averaged out over time, while the if tests seem to gain a 20%-ish boost in speed by using a record, the identity tests seem to be 30%-ish slower than just using a map.