OIDC specifies a couple of important things on top of oauth2. I would welcome it if we implemented it OIDC compliant (since all OIDC is oauth2, this shouldn't be a big deal for those that only care about oauth2).
I don't have time to implement this in the foreseeable future but I'm happy to review designs, I've worked a number of times with OIDC in similar scenarios. Specifically for OIDC for remote-write, we should probably limit ourselves to a few reasonable OIDC-flows that actually make sense for machine-to-machine authn/authz. The use case I imagine is having short-lived tokens that are refreshed relatively often. A common security practice. On Thu, 28 Jan 2021 at 23:45, Julien Pivotto <[email protected]> wrote: > > Dear -developers, > > Per the last dev summit, there is a consensus for having OpenID > connect support for remote_write. > > My understanding and experience of the protocol is that we should > actually aim at oauth2 support, and not openid connect. > > Implementation wise, it would mean sticking to > https://pkg.go.dev/golang.org/x/oauth2 > > Who has an actual use case and can confirm this? > > Regards, > > -- > Julien Pivotto > @roidelapluie > > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/20210128224526.GA1343460%40oxygen > . > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAOs1UmxC63zQP9SPorZPnKXd00SqgFkj44BZxfzPhRA6mPh1GQ%40mail.gmail.com.
