This is actually a good idea, I'll try that, thanks :)
But, you know, it's still a bit more complicated than opening the browser's debug console and inspecting request and response in the networking tab.
Yeah you have operators, which are essentially the auth admins or orgs, however you'd like to look at it, then there are accounts which are an alias for "project name" and then you have users, which are "client name"s.
And that's fine for their infrastructure only.
The problem is, in the real world you have an external identity service (OIDC, IAM,...) and the JWT this service creates includes a subject, but the NATS auth system has no support for external bridges.
Also you have to decide, would you like to use operator/account/user or single JWT, or passphrase or manually managed user/password accounts?
In a professional world, you'd have various customer applications each divided by their operators, accounts and users. And then fine grained user capabilities.. headache time.
So what you have to do is distribute a default user certificate with a client (client meaning actual client in the client/server sense), then do the signin/sso process and have some middleware checking this token from the OIDC auth process and check is a user with this subject exists, if not, create a new user and cert and send that cert back to the client which will then create a new connection with the new certificate.
Very complicated.
The initial default client certificate is required for "logging in" via NATS.
I guess it could be a standalone program, the oidc to nats user mapper/manager.
So compared to HTTP/REST, more work involved.