Openfoodnetwork: Explore Doorkeeper as an Oauth2 auth. method

[RachL]

What we should change and why (this is tech debt)

Following #7339 this mini-spike is here to evaluate Doorkeeper

Acceptance Criteria

We need to be able to answer these questions:

• How long would the most basic pieces take to implement?
• How long would it take to implement OpenID Connect and/or JWT support?
• Are there any immediately prioritized use cases where Doorkeeper does not meet all of our requirements?

[sauloperez]

Are there any immediately prioritized use cases where Doorkeeper does not meet all of our requirements?

I think Doorkeeper is the Rails-community go-to for oauth. That's at least what I used in the past covering all needs, and it's actively maintained.

[RachL]

@andrewpbrett don't know if it is useful at this stage, but the DFC team has documented the OIDC implementation partners have done here: https://github.com/datafoodconsortium/dfc-prototype-V3/wiki/OIDC-Authentication

[andrewpbrett]

Okay, I created a local branch to install the Doorkeeper gem and play around a bit with it. To answer the stated questions:

I think we could have the basic functionality set up in about 2 weeks.

Doorkeeper has an extension gem for JWT support; this would likely be only another 2-3 days to add.

Doorkeeper also has an extension gem for OIDC support; the project is currently looking for maintainers, however. This could be an additional 1-2 week project, or it could turn into something much larger. I propose that we not commit to supporting this just yet.

One thing to consider that came up while I was thinking through this: We currently support a single API key that acts as a personal access token for a specific OFN user. I think we should continue to support this approach; we could also consider extending it such that:
1) A user can easily find their own API personal access token
2) A user can easily generate additional access tokens that could be given to an app developer to grant the app read/write access to the user's data
I think this would take more like 1 week of dev time to implement.

This would lower the barrier quite a bit for someone to develop an application that uses the OFN API since they wouldn't have to implement the full OAuth flow. To make implementing the OAuth flow easier, we could also publish an OAuth strategy for the new OFN provider (1-2 days of dev time). But allowing people to generate and use access tokens could still be desirable to make it easier to onboard new apps.

The takeaways from this spike:
1) Doorkeeper is the winner for being an OAuth provider
2) It'd take about 2 weeks to implement
3) We can proceed with developing endpoints before doing this work, using the auth strategy (personal access token) we have now, since we'll want to continue supporting it in the future anyway.
4) We could also implement the multiple-access-token approach, either as a supplement or an alternative to a full blown Doorkeeper implementation, in about 1 week.

[Matt-Yorkley]

Double thumbs up from me!

I've heard good things about Doorkeeper, and as Pau said I think it's the go-to for oauth in Rails :+1:

Keeping the current token-based auth on the side is probably a good idea as well :+1: I imagine in cases like the test suite or where we are using the API internally, the current option might be a lot simpler, so having both options available seems like a good idea.

[sauloperez]

I think, as we discussed in the last delivery meeting, the tech solution depends fundamentally on the product we have to build and its strategy. To me, both the options you mention @andrewpbrett, API token CRUD and Doorkeeper, are very valid but serve different strategies and goals.

[luisramos0]

Nice, I see this now. Looks good. We can close the spike, right? :clap: :muscle: