feat: support login via oauth

[goatfryed]

I propose to add login via oauth providers.
I'd start with github as a first example case.

If you like the idea, you can assign the issue to me and I'll add it next week.

---

TODO

• integrate the postgraphile library into Nuxt's Nitro server (most likely using @nuxt/kit's addServerHandler)
  • dropping the standalone postgraphile service from this stack
  • removing the JWT functionality from it
  • adding authentication cookie parsing to populate a session id PostgreSQL variable
• add backend functionality for authentication, supporting credential authentication, magic link / email-only authentication and OAuth, taking inspiration from
  • lucia
  • authjs-nuxt (based on auth.js)
  • nuxt example "auth"
  • nuxt module "session"
  • (not relevant seem to be:
    • passport.js (seems outdated / unmaintained)
    • nuxt-community/auth-module (for Nuxt 2 only)
    • sidebase/nuxt-auth (based on nuxt-auth, not auth.js))
• configure sqitch for complete user authentication and session storage (see feat: evaluate redis for jwts #89, which is out of scope here)

[dargmuesli]

Hey there, great suggestion! And great that you want to work on that 🔥
As I don't yet know all details about OAuth, I'd suggest to have a chat on Discord or on a short call.
The requirements that currently come to my mind are:

• for users authenticating via OAuth we need at least their email address so that they can receive one main benefit they take from an account creation: updates to events they attend without the organizer having to know their email address. Would that be possible via OAuth?
• is OAuth a parallel/distinct authentication approach to the current authentication mechanism where the json web token is given directly by the database? Or will it separate just the endpoints so that some of the programmatic authentication route to the backend will be shared?

[goatfryed]

Hey, yeah, lets talk start of next week, when my vacation starts. Basically, oauth provides you just with another authentication way instead of password verification. App authorization stays the same via jwt. The benefit ist that the User doesnt have to create a dedicated Account with ist own Password (for everyone without a PW Manager :) ) and you can directly Access User information like email, name, avatar and more without additional input. Just one click, review accessed data and confirm. Es grüßt freundlich, Omar Sood Jonas Thelemann <notifications@github.com> schrieb am Mo., 7. Dez. 2020, 07:09:

…

Hey there, great suggestion! And great that you want to work on that 🔥 As I don't yet know all details about OAuth, I'd suggest to have a chat on Discord or on a short call. The requirements that currently come to my mind are: - for users authenticating via OAuth we need at least their email address so that they can receive one main benefit they take from an account creation: updates to events they attend without the organizer having to know their email address. Would that be possible via OAuth? - is OAuth a parallel/distinct authentication approach to the current authentication mechanism where the json web token is given directly by the database? Or will it separate just the endpoints so that some of the programmatic authentication route to the backend will be shared? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#90>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIIFZ6434PYUQJE4BCN4KODSTRWSDANCNFSM4UPHKDKQ> .

[dargmuesli]

Here is a 🔥 example on how this can be implemented: https://youtu.be/c_-b_isI4vg?t=8884

[dargmuesli]

To prepare this year's hacktoberfest, I researched the plan for updating the authentication scheme for maevsi:

• integrate the postgraphile library into Nuxt's Nitro server (most likely using @nuxt/kit's addServerHandler)
  • dropping the standalone postgraphile service from this stack
  • removing the JWT functionality from it
  • adding authentication cookie parsing to populate a session id PostgreSQL variable
• add backend functionality for authentication, supporting credential authentication, magic link / email-only authentication and OAuth, taking inspiration from
  • lucia
  • authjs-nuxt (based on auth.js)
  • nuxt example "auth"
  • nuxt module "session"
  • (not relevant seem to be:
    • passport.js (seems outdated / unmaintained)
    • nuxt-community/auth-module (for Nuxt 2 only)
    • sidebase/nuxt-auth (based on nuxt-auth, not auth.js))
• configure sqitch for complete user authentication and session storage (see feat: evaluate redis for jwts #89, which is out of scope here)

As the sum of those changes is complex, any partly progress is highly appreciated! 🙏 Just remember to comment here when you start working on some task so that others are aware of that and can prevent duplicate parallel work.

@goatfryed if you're fine with it, I'd edit your original port and add this plan to it so it's immediately visible for people checking out this issue. Are you?

[goatfryed]

Sorry for the quite late reply. Yes i'm totally fine with your editing.
I was plagued by a bit of illness, but I want to help make atleast a bit of progress here.
I'll investigate your proposed steps and comment, once I start actual work on.

Some more thoughts:

What's the user id of users registered via oauth2 providers? It makes sense to use either email or OIDCs preferred username attribute, but in both cases how do we handle an existing user that registered via another provider (signup/another oauth2 provider).
To keep it simple in the beginning, we could extend the user table by a provider discriminator and verify that as well and reject collisions.
Alternatively, we could just use the email and trust our selected providers that they verify the primary email.

In a second step, we should move the providers to an own relationship and send a verifcation email, if a user wants to connect through a new provider.

[goatfryed]

Okay, i spent half a day finding a working version of docker window. I'll start working on the postgraphile migration

[dargmuesli]

Alright, thank you! Any progress shared is totally fine, it's not required to implement the perfect solution right away in the limited Hacktoberfest timeframe 🙏

I think using the email address as identification is a good idea 🙌
Merging of accounts and such should be an advanced feature that's not necessary by now but of course it's a good idea to already consider it in some way 👌