Doorkeeper VS oidc

The doorkeeper gem.

Take a look at doorkeeper.

Disclosure: I work for FusionAuth.

Depends on what you are looking for.

If you want a standalone auth server, you can use FusionAuth in docker/docker-compose: https://fusionauth.io/docs/v1/tech/installation-guide/docker

You can also package up a library; most major languages have one or more OAuth/OIDC libraries: https://github.com/doorkeeper-gem/doorkeeper for Ruby, https://spring.io/projects/spring-security for Spring/Java, https://oauth2.thephpleague.com/ for PHP, https://pypi.org/project/oauthlib/ for Python.

https://oauth.net/code/ has a further selection of libraries in a variety of languages.

Are there any code examples to implement the PKCE flow in Doorkeeper? I am a bit confused on how to implement it here: https://github.com/doorkeeper-gem/doorkeeper/wiki/Using-PKCE-flow

For authorization we use Doorkeeper gem with PKCE flow.

One thing that is missing from this list is open source language specific libraries. Projects such as https://oauthlib.readthedocs.io/en/latest/oauth2/server.html and https://github.com/doorkeeper-gem/doorkeeper

Depending on your use case, for example if you only have one application, you might be better off running something embedded in your app, or independent but using the same runtime/deployment environment. Then, when you are ready to add another app or integration, you should be able to introduce a standalone auth system more easily if appropriate (because all your auth interactions should be relatively standardized). I'm a big fan of standalone auth systems as a way to simplify access control and give a single view of a user/customer, but you can also succeed using open source embedded libraries.

When the moment comes to introduce a standalone system, you should consider a few dimensions (this list pulled from a previous comment of mine: https://news.ycombinator.com/item?id=26360048 ):

   * open source or not

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.