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

[adrienjoly]

openwhyd.org is an open-source music platform used daily by thousands of users to create playlists of songs from the web (Youtube, Soundcloud, etc...), and discover musical gems from similar users.

Tech stack: Node.js, MongoDB, Docker, Mocka, Webdriver.io, jQuery, Electron + iOS app

---

Problem + context

Openwhyd users are begging for an Android app and background playback of their playlists from openwhyd.org. Both are front-end issues: the Android app could either be a native project or a responsive web app. And the thing is that our current web app (available at openwhyd.org) is not a fun one to maintain, because of the use of ancient technologies (e.g. jQuery), technical debt and the fact that its codebase is mixed with Openwhyd's back-end...

Several developers proposed to create a separate front-end for Openwhyd, for scratch, in order to tackle these issues. For instance, @SkinyMonkey made a React front-end from scratch: https://github.com/SkinyMonkey/sound-nuggets. But he stopped maintaining it because Openwhyd's lack of OAuth-based API (#55) forced him to run a small back-end/bridge online, which was costly.

If somebody could provide a way for front-end clients to auth & connect to Openwhyd's API without requiring to host and run such a back-end bridge, it would be much easier for the community to create and maintain Openwhyd clients on several platforms!

Objective

Allow 3rd-party apps to use openwhyd's API, with user authentication.

roadblock: only cookie-based authentication is provided by openwhyd.org's server, at that point.

leads:

• https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
• https://security.stackexchange.com/questions/20222/oauth-access-token-vs-session-key
• https://developer.atlassian.com/cloud/jira/platform/jira-rest-api-cookie-based-authentication/
• https://stackoverflow.com/questions/17000835/token-authentication-vs-cookies
• https://ponyfoo.com/articles/json-web-tokens-vs-session-cookies
• https://support.3scale.net/docs/api-authentication/oauth2
• https://oauth.io

anybody wants to help?

---

Howto

In order to solve this issue, you are invited to fork this GitHub repository, makes changes to it, and then create a Pull Request so we can merge your changes back to this repository.

First, you may want to read about:

• How to install, setup and run Openwhyd on your computer: INSTALL.md
• How to propose a valuable contribution to this repo: CONTRIBUTING.md

I will be happy to assist you at any stage, if you want to try to solve this issue! If you have any question, just leave a comment below. Beginners are also welcome! 🤗

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[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?