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.
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:
when a user login on the platform we are using Devise on warden
OAuth2 is used to authenticate the user on Stripe’s side
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.
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.
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.
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
Thanks
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
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.
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
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.
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 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.
Consume DFC endpoints thanks to a token + whenever we are logged in on OFN on the same browsers.
Pros: It’s a 5-6h job. Any team wanting to use these endpoints for a particular profile would need to know the token, which is more secure than the emails. Cons: not a long term auth solution, no Oauth2 compliance reached.
Consume DFC endpoints thanks to auth through the OIDC server that the DFC team is using: lescommuns.org
Pros: get us to a full Oauth2 / OIDC compliance, we have a stronger set
Cons: it’s a server that is not widely used. So apart from support team or people interested in DFC endpoints, this auth method would not be much used.
Consume DFC endpoints through our own OIDC server
Pros: Open Food Connect, sounds cool. It would be an advantage if we wanted to allow developers to create apps on top of the OFN API.
Cons: Maintenance and 10h to 20h to add on the original 30h we had for the estimation of this work
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.