Act as OpenID Connect provider

[mkllnk]

Description

An OpenID Connect (OIDC) provider can be used by other applications to authenticate users. We currently use login.lescommuns.org as provider to authenticate requests to the OFN DFC API. But by becoming a provider ourselves, we can authenticate users across OFN instances. That will allow a user of Open Food Network Germany to log into Open Food Network Belgium without setting a new password. And it will then allow the user to move DFC data between the instances. It will also allow new custom apps to use OFN accounts without requiring a sign-up process itself.

Acceptance Criteria & Tests

1. Log into one OFN server using the account of another OFN server.

Existing code

The OFN DFC API verifies OIDC tokens against one provider already:

openfoodnetwork/engines/dfc_provider/app/services/authorization_control.rb

Lines 3 to 8 in 67d5ffd

	# Service used to authorize the user on DCF Provider API
	# It controls an OICD Access token and an enterprise.
	class AuthorizationControl
	# Copied from: https://login.lescommuns.org/auth/realms/data-food-consortium/
	LES_COMMUNES_PUBLIC_KEY = <<~KEY
	-----BEGIN PUBLIC KEY-----

• We want to generate a key pair for each OFN instance. The public keys need to be included in each instance. We can start by hard-coding them and later store them in ofn-install. Estimate 1 day.
• Then we need to handle authentication requests and serve tokens. The tokens must include an expiry timestamp. The expiry should be reasonably short, maybe 20 minutes ans is only used for authentication. Estimate 3 days.
• Lastly, we need a UI for the login within OFN. This should be feature-toggled to start with. When activated, the login-form has a button or link to log in with another OFN account. After clicking that link, the user has the choice of OFN platform to authenticate with. After choosing, the user is directed to that instance for authentication. The other instance may ask to log in if the user isn't logged in already. It then generates the token (see above) and passes it back to the first instance in a redirect. The first instance verifies the token, performs the login, or account creation if necessary, and the user is logged in. Estimate 3 days.

Since each OFN instance is an ID provider itself, it can generate tokens to authenticate any OFN DFC API requests from then on.

Estimate summary: 7 days.

[RachL]

Wooow! Are we sure we want to maintain our own OIDC server? I could be wrong but it seems to me like a lot of work. I would first enable other OIDC existing servers.

What's the need behind this @kirstenalarsen @lin-d-hop ?

[RachL]

Or maybe I misunderstood: this issue would enable to use a "login with lescommun" button and my current OIDC user on FR would be able to login on any OFN instance when this is done?

[mkllnk]

Are we sure we want to maintain our own OIDC server?

Thanks for questioning me here. There are free software solutions out there to deploy and use. So it's definitely worth looking at that option and comparing.

Becoming an OIDC provider came from two use cases:

1. Exchange OFN data between instances via DFC. The user needs to be able to connect two OFN accounts on different instances to move data between them.
2. We want to develop independent apps which connect to OFN accounts to exchange data via the DFC API.

In either case, we could authenticate via a third party but it would be much simpler for users to re-use their existing OFN account. There are several things to consider though:

• login.lescommuns.org doesn't work for a global audience. We need a UI that's better branded and translated. And I'm not sure if any single site would serve all possible OFN users.
• Pushing OFN as single-sign-on may be perceived as monopolising and an independent provider could have better acceptance.
• We may want to support multiple providers though. So if a user wants to exchange data between OFN and XYZ then they need to log in with both and the app connects the tokens to exchange the data.
• A single-sign-on server is simpler to implement then a multi-login-system.
• Integrating OIDC into OFN increases maintenance within OFN but avoids the maintenance of an additional server with its own tech stack.
• Integrating OIDC will probably allow us to create OFN-specific permissions for API exchanges. The alternative to this could be a DFC specific permission system implemented in a DFC managed OIDC server.

I don't think that I can decide this on my own. I'm not even that familiar with OIDC providers. But since we do manage user accounts and have an API, it does make sense to me to authenticate with OFN servers as well. Or, we go into a completely different direction, get rid of OFN instance accounts and move to a global single-sign-on server. That would be much simpler but makes instances also less independent and they become vulnerable to this single point of failure. I would prefer to build on our distributed network of instances and find a scalable solution without compromising user choice on privacy etc.

And it's not like we have to implement everything from scratch. We use an existing library for OIDC for which we just need to add the UX and our custom logic. We could discuss this at the delivery circle but the team probably doesn't know enough about the topic yet. Maybe @Matt-Yorkley and I should have a chat about this first? Shall we work out a time?

[RachL]

Yes sorry I took lescommuns as an example but I def. agree they don't work as a global audience.

It seems to me a bit outside of OFN league to become an auth provider. I fear the monopolistic aspect, but you did a very good summary of the situation, so I don't have anything to add - thanks :)

Looking forward to hear what conclusion will come up from your chat!

[RachL]

Previous thread on the topic: https://community.openfoodnetwork.org/t/allow-other-tools-to-rely-on-ofn-for-user-registration/1456/10

[mkllnk]

I'll close this for now. I don't think that we have a strong enough case for this work. We can setup a global OFN Keycloak if we want. OFN being a provider would simplify some user stories because people don't need to sign up with another server as well. But we don't want to make our code base bigger when there's another solution.