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 lescommuns.org). 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.

thanks!

2 Likes

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 lescommuns.org. The main reason was that lescommuns.org and DFC shared similar values.

DFC documentation on this can be found here: OIDC Authentication · datafoodconsortium/dfc-prototype-V3 Wiki · GitHub

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.

Andy’s investigations of Doorkeeper

Really great investigations by Andy give a good idea about the overhead for different approaches. However we are not yet clear on what our authentication strategy should be. We now know that:

  • The DFC requires OAuth and OICD authentication
  • The token authentication of the current API is sufficient to work with API endpoints
  • We need to balance between the long term view and moving forward with officially supported endpoints

The way I see it we have three paths from here (maybe others see it differently…)

Path the First

Continue with our current authentication using API tokens. Iterate and improve as required.
Pros:

  • Already implemented - let’s crack on

Cons:

  • Not possible to integrate with the DFC

Path the Second

Implement OAuth with DoorKeeper within OFN. Eventually phase out the token based approach.
Pros:

  • Strongly authentication to a widely accepted standard
  • Simplifies DFC integration

Cons:

  • Higher development time required (2 weeks)
  • This would sit alongside the app anyway while OFN uses tokens between front and back end.

Path the Third

Use OAuth in the DFC Engine and keep token auth within OFN. This approach would mean that the OAuth (and OICD) implementation would sit specifically within the DFC engine. The DFC engine would authenticate the user, then make appropriate calls to the OFN API using tokens to retrieve the data and covert to DFC or vice versa.

Pros:

  • We continue to use OFN tokens for API access of OFN apps and services
  • We can connect to the DFC with proper authentication where appropriate to do so

Cons:

  • Maintenance overhead of two authentication systems. Though to be honest it will be a long time before we remove the token system anyway as OFN app needs this between front and back ends.

Thanks @lin_d_hop for this great summary. Here are my questions and comments in case I cannot make it to Monday’s meeting:

My first question goes on the 2 weeks estimations for OAuth: let’s say we stay with token approach until next year, what impact does this have on the estimations? Does the estimation grow because we need to handle migration of external integrations? In that case, is that still worth postponing this work?

Just to be sure this means that it’s sufficient to let devs external to the core team play with our API and even start building production application. Is that correct? Can the token approach be seen as a long term solution?

oh is this what “internal” use of the API means from our previous discussions? I thought that we were mentioning keeping token based approach for things like testing, stagings, local env. etc but not between our front and back. Can this point be clarified?
I understand OAuth as being more secure than token based approach. Can we confirm that our own consumption of the API does not need this?

I just want to stress that I have no strong opinions here, only questions to understand what we are comparing :slight_smile:
Thanks :pray:

I don’t think the estimate would change much by delaying implementation.

It would technically be possible to have the official policy be “if you want to have a third party application access the OFN API, the way you get permission from a user to access their data is to ask them for their API access token”. But it’s definitely not a best practice, and I think at a minimum we’d want to allow users to create new tokens that they can give out to specific applications and revoke at any time (API Token CRUD as @sauloperez put it).

See above :slight_smile:

I’d add one other thing - the Path the Third that @lin_d_hop outlines is one I’d steer us away from (not to get ahead of ourselves or anything). We’d be looking at a similar amount of work (for the non-OIDC part) and a lot less benefit.

Hello, I am not sure this was mentioned in the issue, there’s the doorkeeper implementation in Spree here: Install doorkeeper for OAuth2 in API V2 · spree/spree@57944f1 · GitHub

The spike helped clarify what library we should use: doorkeeper.
But I think the bottom line is still the same: OFN in itself doesnt need oauth right now but if anyone implements OAuth for DFC we should use that sinergy and get oauth implemented across OFN. It should be straight forward to apply oauth across the full app, not just DFC.

Do we have anyone willing (or any budget) to implement oauth for dfc? If we do, we should spec that work so that it includes OFN. If we dont, “Path the First” for the win :slight_smile:

I am not in favor of improving the tokens solution we have. Tokens have quite a few security vulnerabilities compared to oauth, so long term, I think we should go oauth. Oauth is not that complicated after you have it implemented and a nice guide on how to use it from a API user perspective.

Update from our API Auth Meeting:

In the meeting we agreed that:

  • Implementing OAuth across OFN is preferable in the mid term. For this we would use Doorkeeper.
  • We will need to implement OAuth in the DFC engine in the short term.
  • It was reported that by using Doorkeeper within OFN this would not significantly simplify the OFN-DFC Engine authentication. There would be some gains, but not huge.
  • Using Doorkeeper within OFN will help 3rd party developers, however most initial use cases are focused on the needs of instance managers etc. So our short term v1 endpoints would benefit less from Doorkeeper than our mid term ones.
  • Until we implement ReactiveRails the v0 API will continue to use the token system between FE and BE regardless of the decision.

Based on this, we decided that:

  • Our first API priority will not be Doorkeeper in OFN. Instead we will focus on some specific endpoints.
  • Initially we’ll implement OAuth in the OFN-DFC Engine but not on the OFN API.

I’m not totally clear on the details of why implementing Doorkeeper in OFN doesn’t give huge gains when implementing OAuth in the DFC Engine - so I can’t clearly respond to your post @luisramos0.
Perhaps @paco or @apb might be able to offer more insight…?

ok :+1: I dont think it’s a big thing. If we implement oauth in dfc engine first, we can then copy it to ofn at some point. I recomended it’s done in ofn to avoid more work later on.

1 Like