Platform: allow authentication from other domains, for 3rd party clients/apps (e.g. OAuth) about openwhyd

[adrienjoly]

Ongoing discussion about how to integrate external auth (e.g. OAuth) to Openwhyd's back-end: openwhyd/openwhyd-react#5 => your opinion and help is welcome there!

[adrienjoly]

In that discussion, I clarify the reasons why I'd like to encourage the development of new front-end/clients rather than new back-ends (or integrated stacks like Meteor).

[adrienjoly]

https://github.com/ianstormtaylor/permit could be used to create a OAuth proxy to the existing API maybe?

[Brawrdon]

Could you explain how the API works and why you need a host and a "back-end bridge" for it work. Also what exactly does the back-end bridge do?

[adrienjoly]

Thanks for asking, Brandon!

I think that you will find answers to your question in our roadmap.

If there's anything missing and/or not clear enough, please let me know :-)

[Brawrdon]

Thanks! I've started doing a little independent research 😁 (https://medium.com/google-cloud/understanding-oauth2-and-building-a-basic-authorization-server-of-your-own-a-beginners-guide-cf7451a16f66)

Just a quick question, should we stick to using node for the backend? I'm also not sure how to best organise potential changes to the server? Should I do it in another repo for now as I would like to play around with Docker etc. My main focus would be to get some sort of server with basic API + Oauth setup, then integrate that with MongoDB to select user. After that's done then the clients can use the APIs. This is a good use case for Docker too, different containers for the API server and the basic web server!

[adrienjoly]

Hi Brandon, sorry for the delay.

I don't mind adding another technology, as long as it can still run comfortably on our current $15/month droplet (with 3 GB of RAM), together with Openwhyd's Node server and MongoDB.

I may be wrong, but I believe that it would be simpler (for Openwhyd developers) and more resource-saving to have OAuth inside the same Docker container as Openwhyd's Node server.

That said, please feel free to fork Openwhyd and freely experiment with any approach that you find relevant!

There are just a few things I will need to check before deploying the solution in production:

• make sure that Openwhyd's back-end will be working the same way (i.e. no regressions), without having to spend hours reviewing the PR => avoid changing Openwhyd's back-end code, as much as possible
• make sure that the solution will fit our $15/month server => keep the CPU and RAM usage as low as possible
• make sure that the entire solution is stable (i.e. it can run at least one month without crashing)

[uLan08]

Hey @adrienjoly ,

Implementing OAuth in the backend shouldn't be that difficult, the link Brandon gave is also helpful. I could start playing around with it. Could you guide me on the current flow of logging in and also what files to touch?

[adrienjoly]

Sure, I'll try to do this tonight, after work.

[adrienjoly]

Hi @uLan08 !

I explained the login flow in the following file: /docs/login-flow.md.

I'm not experienced with the back-end of OAuth, but I think that the cleanest and safest way to do it would be to create a /oauth path at the root, with several sub-routes:

• the ones required to create a session and renew tokens (e.g. /oauth/create, and /oauth/renew)
• and a /oauth/api/* sub-route that would proxy (some of) the existing API endpoints, by passing over the cookie corresponding to that session, e.g. openwhyd.org/oauth/api/stream would give access to the /stream API endpoint. (the API user would have to provide the OAuth session token instead of the cookie, and the proxy will take care of turning that token into the cookie, so that the original endpoint remains untouched)

Alternative ways to do it:

• create another middleware that would enable the current API endpoints to extract the session either from a cookie or from a OAuth token
• or wrapping/changing the logic of the existing API endpoints in order to do that without touching the middleware. (note: this may result in a quite fluffy and risky PR to review and merge...)

In order to implement the first solution I proposed, I believe that you will have to:

• add a OAuth controller in /app/controllers, that would contain both the token management endpoints and the proxy to the legacy/cookie-based API
• add the corresponding route(s) to app.route, possibly taking some inspiration from the pattern used in /app/controllers/subdir in order to allow recursive/hierarchical sub-paths

Please let me know if you need more assistance! I'll do my best to help!

[adrienjoly]

Hi Patrick!

Are you still motivated to propose a solution to this issue? Let me know if I can help in any way!

[uLan08]

Hey adrien, Yeah, just a bit occupied. But feel free to have a go at it if you want. I can't promise a definite timeline yet.

…

On Sat, 3 Nov 2018, 18:12 Adrien Joly ***@***.*** wrote: Hi Patrick! Are you still motivated to propose a solution to this issue? Let me know if I can help in any way! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANgZoJhbN4FMkbQfU6qT-TbNrUomChoZks5urWwJgaJpZM4OT_zn> .

[adrienjoly]

No worries, I was just checking if I could help ^^

Have a great weekend!

[adrienjoly]

If any of you are based in Paris and available tonight, I propose that we work on this topic during the "hackergarten" meetup: https://www.meetup.com/fr-FR/Paris-Hackergarten/events/tvdrwpyxpbkc/

[adrienjoly]

Other possible solution: "Grant: OAuth Middleware for Express, Koa and Hapi" (https://github.com/simov/grant)

[adrienjoly]

A crash course on securing Serverless APIs with JSON web tokens

[adrienjoly]

For reference, we had started using oauth2-server - npm, with Dhafer Dhib, during Hackergarten. I'm considering to follow that route today.

[adrienjoly]

WIP: https://github.com/adrienjoly/oauth-bridge

[adrienjoly]

I just discovered https://oauth.io/ and asked them by email if they may be a good solution for us.

[adrienjoly]

OAuth.io would be to provide assistance if we decide to become a oauth2 provider.

They have a Node SDK that could easily turn our existing server into an OAuth provider: https://github.com/oauth-io/oauthio-server-node

Before checking that out, they suggest looking at the most bare bone example of a Node/Express server using the SDK to become an OAuth provider: https://github.com/oauth-io/provider-node-example

There's a step-by-step on video there: https://cl.ly/3a3x1I3W1r2b

Advantage of using their platform: Any dev that wants to use Openwhyd's OAuth API merely needs to click 'Auto-Configure' on OAuth.io, which automatically provisions the app on our OAuth server, and transfers the keys over to OAuth.io, and they are set. Demo: https://cl.ly/2n2b1k0T142R

Note: it would probably make it easier for us to do that if we migrate to Express.js first => #122.

[adrienjoly]

Could also be used: simov/grant: OAuth Middleware for Express, Koa and Hapi

[adrienjoly]

Also to check out: Implementing an OAuth Server With Node.js and Express | www.thecodebarbarian.com

[adrienjoly]

Note: we should reflect on whether or not we need OAuth.

E.g. could we pass a session cookie as POST parameter instead?