OpenID Connect (OIDC) / OAuth2 authentication solution for DFC (and maybe more)

The Data Food Consortium (DFC) API connection will require an authentication through OpenID Connect (OIDC) protocol.
Actually, the DFC prototype will request the DFC API on OFN application, using an OpenID Connect token generated from an external OpenID Connect server (today We will then need to verify this token to authorize the request.
As OpenID Connect is based on OAuth2, my idea was to use the omniauth-oauth2 gem (GitHub - omniauth/omniauth-oauth2: An abstract OAuth2 strategy for OmniAuth.omni-auth) to proceed this external authentication. Does it sound good?

Also, this OAuth2 integration could help to use Facebook Connect or Google Connect for example, I don’t know if it is something we want but we could discuss it here too.

1 Like

Hi @paco great.
I think this should not be specific to DFC, we should implement this in a generic way that can be used in the OFN REST API as well. Actually, this could also be used in the app, “login with google” type of thing. We could do for example “login with solid” at some point.

Re the gem, have you looked at other gems? Would be good to see what are the alternatives before deciding.



Alright so we add a chat today with @paco who helped me to have a clearer understanding of which authentication methods are used today within OFN and which options are possible.

Maybe it’s not 100% the correct place to document this, we can move this to another threads once we are clear on the next steps.

What authentication methods are currently used by OFN? If i understood correctly:

OAuth2 and OpenID Connect (OIDC) are two complementary standards: yet, while OpenID Connect is based on OAuth2 and cannot work without it, OAuth2 can be implemented alone.

When using OAuth2 or OpenID Connect, you need to use a server that will handle the authentification. If I got it right, Doorkeeper is basically an authentification server. For DFC work, so far we are using an OIDC server hosted by The main reason was that and DFC shared similar values.

Microsoft, Apple and Google are already providing OIDC services (see this list), so if one day we want to add a google connect or equivalent as a login option to OFN, it will be possible. It’s out of the scope right now, but as we are only at the inception level, it might be good to keep this use case in mind. That being said this use case can also be applied with OAuth2 alone.

Anyway, my conclusion on this so far is that we need to have a clear view on how to approach the authentication method topic within OFN (what’s used to login, what’s used for the REST API), and from there how to deal with it when working on the DFC connector which requires OIDC.

Maybe the best would be to start by a dev spike? @lin_d_hop does that sound like an interesting starting point in the API roadmap?

Nice work Rachel!
A spike would be good to define the solution to be used. I think we will end up just implementing oauth2 all over. I think we need to evaluate the use of jwt as well. Using jwt with oauth2 brings a few advantages over using only oauth2.

This sounds like a really good starting point @Rachel
I think it’s time for another meeting on the API Strategy… :slight_smile:

Update: we agreed in delivery circle that it makes sense for @apb to look at the spike to balance his current work on the Rails 5.2 upgrade and s2 fighting.

To do the spike, we agreed with @apb that we would move forward step by step.

First step has been done by @apb this week by documenting our current authentifications methods up here: Authentication · openfoodfoundation/openfoodnetwork Wiki · GitHub

Next step is to explore Doorkeeper. Stay tuned.