oidc VS PHP OAuth 2.0 Server

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.

For creating a PHP OAuth2 server take a look at https://oauth2.thephpleague.com/ it is not a complete server, but will do most of the work for you.

For the server side, I'll use the OAuth 2.0 server library. The implementation here is more complex, as there are many moving parts that need to be in place.

I looked at the phpleague oauth2-server and there, they say that a SPA (front end in angular or react) should use Authorization code grant and not password grant (it seems password grant is not recommended to use anymore).

Laravel Passport facilitates full OAuth2 server implementation for Laravel Apps in less time. Developing an OAuth2 server from scratch can be tedious and time-consuming, but Laravel Passport is a local OAuth 2 server for Laravel apps. The Laravel Passport package embodies routes, middleware, and database migrations to develop an authorization server that will return access tokens for giving access permission to server resources. It uses the League OAuth2 Server package as a dependency and has a straightforward, easy-to-learn, and easy-to-implement language structure.

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.

I completely agree with this!! Sometimes there's too much hubris in OSS; classes made final, methods made private- because the author has made their mind up about how the library should work and be used. But sometimes it's not possible to imagine every use case. If software is extensible and someone breaks their app by extending your library and doing something wrong, that's their problem. Take a look at this for example: https://github.com/thephpleague/oauth2-server/issues/885 here the authors don't want to make it more extensible because some people might encode too many claims into their tokens and run into problems with header size. Ffs get off your high horse and let people use their own judgement !! /rant

https://github.com/thephpleague/oauth2-server is also good

Otherwise, if I need something larger, then I would go towards OAuth and than in particular OAuth2 from the PHP league. It provides a good framework to work with to implement authentication in your project. Setting up is a bit of work, but when it works, you don't need to look at it again.