OIDC

[KoltesDigital]

Hi @trasher,

I think your plugin only needs a few changes to be OIDC compliant. This would be awesome because it would increase so much the amount of web apps that could identify with Galette. Of course, I have the personal case of a website that can connect with OIDC but not with OAuth2.

However, I've quickly tried to do it, but I failed. I've read in a forum (I'm French too) that you're not confident regarding OIDC. If it's still the case, I can help, at least for design. I haven't coded in PHP for a long time, but I could try.

This repo can be helpful too.

Besides I don't have a good env to work on PHP and the plugins. I mean, I've tried to change every case-insensitive occurrence of OAuth2 to OIDC, to change some constants accordingly, and to upload that to a new directory in a Galette instance I have, but it somehow freezes the original plugin as well. Can you please provide some guidance? I haven't found any on the doc website.

[trasher]

Hello @KoltesDigital,

(Note: I'm not the author of the OAuth2 plugin, I just made some quite minor changes on it :))

The only thing that has been done is to provide a set of data which try to respect an existing schema: it's way more simple than creating/maintaining a specific one.

I had the idea to work on that because I saw the following fork:
https://github.com/flh/plugin-openidc (BTW, it is maybe compatible with recent Galette versions; maybe would it just suits your needs?)

This fork uses https://github.com/limosa-io/openid-connect-server - that seem to be a (less popular) equivalent than https://github.com/steverhoades/oauth2-openid-connect-server.

I guess having a plugin that would provide both with less effort would be great.
But unfortunately, I still have almost no skills on all those technologies, I really have no idea how to make all of that working together (I would be incapable of even trying to explain the difference to anyone).

As far as I can see, the forked plugin has quite a lot of specific changes; but it was based on an old OAuth plugin version (before I made changes to data set, scopes implementation, etc). I do not know the reasons of the changes they made on their side :/ I do not even know why it's been forked at the origin.
Maybe @flh (fork's author) could tell us and give his opinion?

As of helping on dev, I'm afraid you'll quickly face issues that are specific to oauth/oidc - and not Galette. You should start with enabling debug mode, and check what logs are saying. I can maybe help if problems are Galette related.
It's possible to rely on [old plugins dev documentation](https://web.archive.org/web/20210928051351/https://doc.galette.eu/en/master/development/plugins.html#internationalisation: many things will no longer work, but it may help you to see the big picture.

[KoltesDigital]

Sorry I thought you had taken over it, because of the lack of fear regarding breaking things :)

I didn't know about the fork. Admittedly the best would have it merged into this one, let's wait for a message from @fhl.

Quick explanation. Let's say you want to do an action on service S that requires permission P. S delegates user database to external service O, because it's far easier than implementing yourself this feature (you'll end with security holes if you do!). So S relies on O, through the OAuth2 protocol. If you send a request to S, you'll have to send a token along with it (e.g. in Authorization header) that comes from O. So you authenticate to O, and O gives you a token. You give this token to S with any request. S verifies that the token comes indeed from O (e.g. because it's signed with public/private keypair), that the token has been made for S (through the audience claim), etc. Ultimately, the token contains the information that you are allowed the permission P. So S lets you do the action. But S never knows who you are.

That's not at all what this plugin is doing. Instead, the token granted by the plugin is then used to query the plugin again, on the user endpoint. The response is data about who the person is. So S has to somehow map these data (e.g. using the user id, or the groups the person belongs to) to its own set of permissions. That's what OIDC is about. And that's why I think the plugin is almost ready for OIDC, because it's actually closer to OIDC than to OAuth2. It's just a matter of changing some terms and some routes to make it compliant (e.g. user data are actually contained in the id_token so there's no need to send a second request).

[flh]

I can confirm that the fork works fine with recent Galette versions. It is currently working fine on a Galette instance. I'm using it as a SSO provider for Wordpress, Sympa (using Apache OIDC plugin) and Nextcloud.

I tried to reach, a long time ago, the original author of the OAuth2 plugin, without success (I'm not sure I got the right address, could be my mistake). Eventually this plugin went its own way.

There are a few compatibility issues with respect to the OIDC spec (causing sometimes weird error messages from Nextcloud, which I didn't have time to investigate). I'm also not completely happy with some parts of the implementation (I started many changes in a really hacky way, and left them untouched since everything started working).

From what I've learned, OIDC is close to OAuth2, yet implementing a server needs to change quite a few things (some response types from PHP League OAuth2 Server need to be completely changed in order to answer correctly to OIDC).

I would be really happy to improve my current implementation (including changing the dependency on the openid-server implementation), updating it and try to merge it with the oauth2 plugin, or helping in any way, although I won't have much time for this project until a few weeks from now.

[trasher]

@KoltesDigital, @flh thanks for the feedback! 👍

I really think those plugins are a a great plus for Galette users; that's why I've spent time to made changes and improvements on OAuth2 one.

You both confirm what I understood: both are almost the same. So, we really should have only one plugin; it would be way more simple for users and probably for maintainers as well.
I do not know yet if I can do the work; but I can take an eye.

I've tested a lot OAuth2 plugin against a Flarum local installation with a dedicated plugin. OIDC plugin for Flarum is not free (I'm not going to pay for that :D).
What would you recommend me to use so I can try to work on that subject (excluding Nextcloud, it's always a nightmare to install :/)?

@flh for the moment, if the idea is to merge both plugins, I think there is no need to make changes on your plugin, especially if it currently works ;)
My idea is to setup a 3rd party soft that will use Galette as OIDC provider, see what your plugin does and try to reproduce with OAuth2 one.

@KoltesDigital, there are not much breaking changes; but there were "suspicious" data "coming from nowhere" (that can be re-enabled from config), some wrong comprehension/implementation (options used as scopes, groups that are not Galette groups, etc), ... And no final release has been done yet ;p

It's been a while I did not heard from the original author of the plugin, maybe @manuelh78 would want to give his opinion?

[flh]

You could try and use Apache auth_openidc module. I'm using my plugin with a config like the following:

		OIDCClientID galette_some_name
		OIDCClientSecret a_random_secret
		OIDCProviderMetadataURL https://galette.example.com/plugins/openidc/openid-configuration
		OIDCRedirectURI https://another.example.com/uri/after/login
		OIDCCryptoPassphrase something_random_for_apache_not_related_to_galette_plugin
		OIDCScope "openid email profile"
		OIDCResponseType id_token
		OIDCPassIDTokenAs claims
		OIDCPassClaimsAs both
		<Location /uri/after/login>
			AuthType openid-connect
			Require valid-user
		</Location>

It only requires an Apache HTTPD setup, nothing else.

I've also used my plugin with Wordpress extension openid-connect-generic : https://github.com/oidc-wp/openid-connect-generic

Making Apache auth_openidc and Nextcloud work exposed a lot of bugs in my code: they seem to be more strict than the wordpress extension, both in different ways.

[trasher]

OK, thank you very much :)
Indeed apache only approach may be enough to see how it works. I'll take an eye when I'll have time.

[KoltesDigital]

@trasher Regarding clients, as an exercise to get the full picture, I'd recommend to go raw. Take any REST client, or even curl. If you're in VS Code, there's a nice extension (humao.rest-client) that uses a tab to build a request, so you can easily switch between multiple requests.

Regarding servers, you may take any "well-known provider", e.g. GitHub. But if you really want to play with it, you may easily have a Keycloak instance on Docker.

[trasher]

Well, curl/rest solution would be great to learn in details; but this is not my goal. It would be easier to use a client which already implements required requests; using real usage cases seems a better start for what I want to achieve.
As of the server... Well, it's the purpose of the plugin :)

[KoltesDigital]

In case you want to compare with what a compliant implementation would respond ;)

[trasher]

I spent some time thinking and working on this, and there are several problems.

First of all, fork plugin is not really usable:

• there are many changes that would be hard to reintegrate for now, including required tables in database.
• it relies on implicit grant, which should not be used.
• it does rely on a no longer maintained lib (1 commit in 3 years, support for PHP 8.1).

So, I made some search, and it appears that almost all OpenID Connect PHP libraries are sort of dead :/ I did not find any reliable maintained one (steverhoades/oauth2-openid-connect-server had no commit in 2 years).
Therefore, if we want to add that support in the plugin, it should be done "by hand" (building plugin owns oidc on league/oauth2...).

I'm not yet sure that would work as expected; and that seem a quite huge job to do, especially as I'm not an expert on those subjects.

Seems like database table from fork provide extra features; this does not seems mandatory for odic implementation. Yes, those features can be of interest, and also for oauth2; but that also require a lot of work for securing and cleaning.

I guess it could be possible, in a best effort, to have a partial support of the basic OIDC compliance. The question now is, will that be enough... :)