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.
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.
That depends, define ‘passwordless’ .
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.
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.
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.
All good, the blogs will help a lot. It’s normal to get confused reading the code .
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.
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.
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.
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).
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
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
By relying on blueprints (although slightly modified for this skeleton) we can deliver different features separately and you can mix and match the desired auth features you like in your application. For these blueprints, tests have been written (which are set up via the programmatic API of FSM). The skeleton itself was tested manually, as always, it’s a learning resource primarily. Compared to the old skeleton, a lot was cleaned up and resource management is now done entirely via FSM.
As always, comments, pull requests, implementations in your own FE/BE language are welcome.
.
.