oidc VS go-oidc

Zitadel OIDC library code is very well-writen and informative.

Highly encourage everyone jump into source code and explore how IntrospectionResponse struct work with all related code around

https://github.com/zitadel/oidc/blob/main/pkg/oidc/introspec...

// IntrospectionResponse implements RFC 7662, section 2.2 and

// OpenID Connect Core 1.0, section 5.1 (UserInfo).

// https://www.rfc-editor.org/rfc/rfc7662.html#section-2.2.

// https://openid.net/specs/openid-connect-core-1_0.html#Standa....

type IntrospectionResponse struct {

I started with https://github.com/zitadel/oidc/tree/main/example/server/storage

oidc: github.com/zitadel/oidc (certified by OIDC)

I had to set up a OIDC server so our website could act as OIDC provider, and was really surprised how hard that is to do if you simply need the most basic setup. In fact it would seem that everybody would just keep a Keycloak or whatever— in their cluster and would keep it up-to-date with whatever user schema they would have in their app. This felt like too much work for me (I didn't want to maintain a whole extra service to just be able and provide a couple Oauth scopes from our API back-end.) so instead I went on and implemented the server directly in our app using https://github.com/zitadel/oidc. In fact this was the only fully-functioning OIDC implementation in Go that I could just plug in and make it work. So big props up to the Zitadel guys, the only worry would be from my side that the server implementation could be more generic and could rely on a set of interfaces that the users would be able to implement easily, without having to import a bunch of code from 'examples/server' like we have to do at the moment?

I just wanted to spread the word, that we moved the library to a new home in the ZITADEL GitHub organisation to ease some of the confusion around the name of the company (CAOS) and the project (ZITADEL).

But to ease the pain of this we release personal access tokens in March and are currently prepping to support client credentials as well, thanks to a contribution.

I use the following code with this lib

If oidc supported, check out https://github.com/coreos/go-oidc You can instantiate a oidc verifier by passing the oidc-configuration endpoint, set the remote public key set by passing the jwks endpoint. Then call Verify func. As long as the public key matches the private key used to sign the JWT (3rd part), you'll verify it and get the claim back, then unmarshall that claim to some struct and you're good to go.

This looks so far like some of the nicest ones. I'm sold if you add the possibility for OpenID connect authentication that can be configured via env variables to the container.

I did everything according to go-oidc examples: https://github.com/coreos/go-oidc/blob/v3/example/idtoken/app.go

go-oidc: github.com/coreos/go-oidc

If you actually have OpenID Connect then there are some good libraries to use for token management in that case. Iirc I prefer https://github.com/coreos/go-oidc, since it supports auto discovery and key rotation etc.

oklog/ulid to generate IDs. coreos/go-oidc for validating JWTs I get from auth. google/go-cmp for comparing structs in tests (unless the project is already using Testify). spf13/pflag because life's too short for Go's flag handling. getkin/kin-openapi for validating reqests/responses against my OpenAPI spec (in tests).

Hmm, this might be a relevant issue: https://github.com/golang/oauth2/issues/128 . On the face of it, it looks like https://github.com/coreos/go-oidc is a more thorough implementation...(?)