Authentication in FaunaDB skeleton repository preview

Help
#1

Hi folks,

I have just put the repository that I am working on in combination with a series of articles public: https://github.com/fauna-brecht/skeleton-auth Consider it currently ‘in review’. Therefore, it’s currently still on my personal GitHub user and not an official fauna repository yet, but we figured that it might already be interesting to preview (or it might not be interesting, in that case, that’s valid feedback).

The basic content (a frontend only approach and an approach with a partial backend) are separated in two different branches. Extra features are added later on with separate commits so you could check out the simple branches first and see what code is added for a specific feature.

image
image768×363 40.7 KB

I am, of course, very interested to hear what the community thinks. Bear in mind that I’ll be away next week though. The commits show what the different features are. If navigating a repository is not your thing, no worries, the articles are coming. We simply wanted to already provide a preview for the people who are waiting for this content and might want to look at the code/approaches.

4 Likes
#2

will this implement password less login?

#3

Wish I could add more hearts! I am very excited.

@vasco3 The README puts 3rd party identity on the roadmap.

1 Like
#4

That depends, define ‘passwordless’ :slight_smile:.
If that means ‘magic links’ then I would say, I thought about it and last minute removed it from my ‘extras’ since it’s often frowned upon by security experts.

If that means ‘SSO’. Yes! as @ptpaterson indicates. We will add branches that implement SSO by using external identity providers once the features that are on the roadmap are out to support this integration in a more elegant way. At this point we don’t intend to implement SSO manually.

We will probably add a SuperTokens integration (an npm library) as well which radically simplifies the second example with a backend refresh/access flow and provides you with more advanced security features out-of-the-box (techniques such as browser sync). We are very interested to hear whether that sounds interesting and justifies a license.

2 Likes
#5

This would require some meaningful modifications to work in a serverless stack though, correct? Netlify functions for example are stateless so without session you would have to go the JWT route I presume.

EDIT: For anyone reading, I implemented this in netlify functions with the help of this article: Build an authentication service with Netlify Functions - DEV

#6

The refresh tokens are kept in http only cookies. That is, they are saved pretty securely with the client, and passed back to serverless function (or Express API in this case) to be used serverside. No state is being saved on the function-server or express API.

1 Like
#7

Right, my bad. I still decided to go the JWT http-only cookie route to do some future-proofing.

Another doubt: isn’t the ‘register’ backend function incomplete? It doesn’t return the refresh token nor the access token to the client (https://github.com/fauna-brecht/skeleton-auth/blob/backend-partial/backend/routes/api.js#L47)

#8

All good, the blogs will help a lot. It’s normal to get confused reading the code :slight_smile:.
I specifically chose not to return any token from that query as later on when you add email verification it doesn’t make sense to immediately grant access to the user (which you can find in the backend-partial-extras branch.

So in this case you have to:

  • register which just created a user
  • the user then has to login separately.

You could merge these two steps and immediately log in the user, which I didn’t do because of the feature that came later:

Later in the extras-branch:

  • register which creates an unverified user and send an email
  • user clicks email verification link and becomes verified.
  • user has to log in.

Even in that last example, I could have merged the last two steps but that should be easy to modify in case you want to provide that UX. Keep in mind that it also means that if someone hijacks the email (although unlikely) they are in as well without having to provide a password.

#9

That’s what I’m trying to do using Netlify functions. Having some problems with the saving/retrieving of the refresh token, since middlewares aren’t possible as far as I know.
I know that databrecht is working on a serverless implementation of the backend-partial approach. That would be tremendously helpful.

#10

True, but I have to warn you that I am currently working very hard on providing examples for some upcoming exciting features (one of those also regarding auth) so I might not find time immediately. Noted though that I should really make a skeleton that is easy to deploy on Serverless providers! Top of my list for the end of the year.

1 Like
#11

@alfrenerd Instead of express middlewares, you would likely handle the cookies yourself.

You can see how to work with cookies in Netlify functions from their example. It uses the cookie npm package.

2 Likes
#12

Would love to read more on this as it’s the first time I’m seeing it (In fact, I’ve often heard the opposite of how passwords are frowned upon). Could you please point to some further reading on the subject?

Also, SuperTokens looks really cool! Would love to see an example integration with Fauna.

I’ve personally been looking into https://workos.com/, which is aimed at making it easier to go upmarket with Enterprise SSO integrations, but also supports consumer SSO providers (and magic links haha). The really nice thing about it is the pricing scheme that doesn’t charge per user for consumer SSO accounts (in fact it’s completely free if you only have consumer SSO accounts).

#13

@lewisl Check out GitHub - magiclabs/example-nextjs-faunadb-todomvc It uses FaunaDB + https://magic.link :slight_smile: for password-less auth.

If you’re going to play around with it, be sure to check this issue Convert project from deprecated permissions scheme to using ABAC · Issue #2 · magiclabs/example-nextjs-faunadb-todomvc · GitHub for a guide on how to update the example to use ABAC.

Check out Magic.link’s security docs for a better understanding of how it works! Security | Magic

#14

I will add this before you read on, I think this is quite opinionated. You might argue that users who can’t keep their emails secure might not be able to keep their passwords secure either. I however, agree with their points, others might not :upside_down_face:

I tend to read a lot what security experts have to say like: Troy Hunt: https://twitter.com/troyhunt/status/1058302393752768512?lang=en
He doesn’t explain why though so let’s look for other resources:

There is this about password reset (reset links are arguably very similar to magic links), which has one important phrase that probably summarizes where his opinion comes from:
" your mailbox should not be considered a long term secure storage facility"

From this post, you can see that it’s advised to add extra security measures like additional questions before you reset an account. The problem with magic links, is that they are essentially similar to these reset emails, but they are often valid longer and almost never included extra security measures (because that would make them annoying to use).

One that details why he thinks they are bad.

And another one with pro’s and cons.

Second links, doesn’t say they are bad, but does list these disadvantages:

  • To keep magic emails secure beyond doubt, users need to protect their email accounts with multi-factor authentication."
  • Unless users access their emails through encrypted networks, hackers can intercept less secure connections and steal the session token from a magic link.
    We can all agree that many users are not capable of the above :slight_smile:
2 Likes