after which support for basic auth and auth token has been added to logcli as cli arguments, but in our case (with multi factor authentication required and without browser on host) this is not enough. We try to achieve token using oidc-agent but without success result.
IMHO sh0rez 's proposed solution is naive implementation. OAuth 2.0 has more flows, not just the most used Authorization Code Grant - I would say RFC 8628: OAuth 2.0 Device Authorization Grant is more suitable for this use case. But not all Identity Providers (IdP) may support it.
I would recommend to add small change to logcli: watching changes of bearer-token-file. Then it will be user responsibility to maintain valid token in bearer-token-file, which is another complex problem and it depends on used IdP and IdP configuration, e.g. some flows may be disabled, some additional sec. features may be required (especially if you are in the enterprise env), …
It will be a huge challenge to implement oauth/oid in properly in logcli with support for all possible IdP authentication options.
My personal opinion is that it’s generally a bad idea to do authentication directly on Loki for several reasons. Personally I let Nginx take care of authc/authz (without oauth for us), with user / org mapping, and you can probably do the same with some sort of oauth module.
That’s the server part. You can add some fancy oauth/oidc authentication/authorization/audit/mapping proxy in front of Loki.
But now how do you authenticate client (logcli)?
Especially if it has limited access to the browser, where sso session is stored usually.
