Providing an Oauth2 endpoint from drupal.org

This is something we’ve been looking at for integrating 3rd party services, but these haven’t gotten quite to production yet.

oauth2_server is the most promising implementation I’ve seen. A thorough security review of the module would be great.

I’m curious how continuous integration might use this.

A hesitation for opening something like this to the world is handling support issues which will come up.

@drumm After speaking at DrupalCon Vienna in a BoF about it, what's the current status and internal planing on this?
How can the Drupal community help and support the infrastructure team here?

Because of a related discussion on drupalchat.eu where such an authentication was mentioned as an "anti spam" solution we should maybe filter on "confirmed" user role.

I still haven’t seen a security review of the project.

Is this just installing oauth2_server on d.o or would we go and deploy a separate instance just doing the authentication?

@sanduhrs A Subdomain like "openid.drupal.org" with a D7 System and bakery-module would be possible. Maybe not good for usability but easier to accept for d.o infrastructure maintainers.

D7 because of the bakery dependency?

@sanduhrs Yes that was the idea. But maybe the D8 version of bakery can be pushed forward. By myself I'm not very motivated to push bakery because I like the openId/oauth2 way. But bakery is already used on d.o infrastructure as far as I know. So this can be a way to push oauth2 via a bakery solution :-)

Maybe my suggestion above is not good explained. When the d.o-Maintainers currently don't want a direct implementation of an oauth2 endpoint on drupal.org there is possibly an chance to to run a bridging system. For the bridge we need a subdomain like "openid.drupal.org" which is connected via bakery to drupal.org. For the other side the bridge system can provide an openid/oauth2 endpoint to connect other systems like "drupalchat.eu". To realize this we also need support of d.o-maintainers e.g. for getting a subdomain. With this workaround we can move on and maybe this helps to get finally the endpoint directly implemented on drupal.org.

In the past it was easy to connect community sites to drupal.org e.g. the german forum "drupalcenter.de" via bakery. This community feature was gone because of security. Maybe in future there will rise another security problem with using cookies and bakery will be not working any more in d.o-infrastructure. Because of this risk it's a good decision to early start testing and improving an openid/oauth2 solution as an alternative to connect "groups.drupal.org" and other *.d.o systems. And finally I really like to get back the community feature "login via drupal.org".

@C_Logemann - Just to clarify - the D.O maintainers (including myself) actually do want a direct implementation of an Oauth2 endpoint. We're working on a review of the existing available modules from a functionality and security perspective this sprint and hope to be working on this over the next several sprints. So hopefully we do not need to rely on a more complicated work around to make this happen.

In the past it was easy to connect community sites to drupal.org e.g. the german forum "drupalcenter.de" via bakery. This community feature was gone because of security.

The old system actually predated bakery, it was Drupal’s XML-RPC implementation, https://www.drupal.org/node/1105470. And yes, it had some big security issues.

@drumm If a security review is needed, I will see what I can come up with.

Are there other ways to bring this forward?

Need to update the issue summary with recommended OAuth2 servers config, like various token lifetimes.

So I recommend the following timeout times:

• Access token lifetime: 300
• ID token lifetime 300
• Refresh token lifetime 3600

This would be really helpful especially with respect to different DrupalCamps using different logins; which becomes a nuisance to manage.

The ability for DrupalCamp websites and other services serving the Drupal community to offer SSO would promote participation in drupal.org while improving security for users and the Drupal community (e.g. by avoiding identical passwords being used across services and reducing attack surfaces of other services).

If a service (e.g. a DrupalCamp website) had the ability to discover whether a given user has a Drupal Association membership, it could also empower services to more actively upsell users on DA memberships or offer perks to DA members (e.g. reduced admission).

There was talk at some point of the NYC Drupal community seeking individual memberships to help fund its programming and build community. It would be great for DrupalNYC and other local organizations to be able to require (and seamlessly validate) DA membership as a prerequisite for local association membership to avoid unintentionally redirecting membership dollars from the DA to the local associations.

Making the title more explicit for better searchability.

Is anyone aware of an oauth server module for Drupal that has been used in an environment that got a security audit?

I think #3049462: Roadmap for a stable release? would be great to finish along with the launch.

I'm wondering if Simple OAuth (OAuth2) & OpenID Connect may be the better choice now given what was written in #3198714: Migrate to the League's PHP Library. I didn't see a security-review issue in that queue, however, like there is for OAuth2 Server: #3038634: Security review, which actually points here.

As the person who created the story that suggests the OAuth2 Server module should migrate to the new library. Please be aware that the two modules have a different security model.

OAuth2 Server only allows the intersection of a user's permission and the application's scopes. (My personal view is that this is what you expect with OAuth).

Simple OAuth in contrast sets the permissions of the user to that of the scopes provided to the accessing applications. This can give the user fewer capabilities but it can also give the user more capabilities. As outlined in #3077125: Consumers should not be able to grant roles beyond those already assigned to user by the module maintainer, this behavior is by design.

Depending on the use-case, the model in Simple OAuth may or may not work for you.

We are actually getting pretty close to deploying KeyCloak as an OAuth solution. We are in the phase of testing user migrations now.

There have been many barriers along the way, for example, until only a month or two ago KeyCloak did not support two factor recovery codes. We've been working with upstream on things like this to get to this point.