DEV Community

React authentication, simplified

Tyler Warnock on May 03, 2021

Authentication is one of those things that just always seems to take a lot more effort than we want it to. To set up auth, you have to re-research...

Read full post

Warren Parad • May 4 '21 • Edited

Need to be careful of a couple of things:

Article suggests using the Auth0 jsonwebtoken library, but this one doesn't actually support all the necessary token types
Specifically it seams that UserFront creates RSA tokens, when this is no longer the best solution. It may be good to check out the alternatives to see if one of the standard SaaS solutions does provide this
The JWT in the article isn't a valid access token according to the openId specification. This is pretty common problem which makes it impossible for clients and users to integrate effectively. It should look something like this:

{
  "iss": "https://authress.io",
  "sub": "user_100822687410662214374",
  "iat": 1620125048,
  "exp": 1620211448,
  "scope": "openid profile email",
  "azp": "api.authress.io",
  "client_id": "9fe39cec",
  "aud": [
    "accounts.api.authress.io"
  ]
}

Tyler Warnock • May 4 '21 • Edited

Thanks for your thoughtful response @wparad !

For context, we are building Userfront for simplicity and usability in the vast majority of use cases. In doing so, we use defaults like userId instead of sub so that it makes sense to most developers without having to delve into confusing terminology. We will eventually introduce the ability to format tokens to different standards for specific use cases like you mentioned, but for now we present it as simply as possible. It's worth pointing out that all are valid JWTs according to the JWT specification.

Would love to hear more about your comments on the jsonwebtoken library. It is easily the most popular library and why we recommend it. What do you not like about it?

For RSA, that is the NSA's recommendation, so that's what we use. You'll have a tough time convincing us otherwise!

Matteo Frana • May 6 '21

Hi Tyler,
great article and it seems a great product.

The 10.000 monthly active users means that if I have 1.000 users they will be able to login as many times as they like and I will be always in the free tier?
I'd like to use your solution for two upcoming projects. In one case the customer needs to have all the data in the EU for their privacy policy: is there the possibility to choose a EU zone for the data storage?

Thank you,
Matteo

Tyler Warnock • May 6 '21 • Edited

Hi @matfrana ,

Yes that's absolutely what it means -- we want to offer free auth for small projects, and in general we want best-in-class authentication to be free for any project that needs it, because that will make the internet better. 1,000 users is no sweat for our infrastructure, so yes it is and will be free.

For your EU question: we don't currently offer the ability to store all data in a given location, and it's currently housed primarily in the US. Your request is a common one though, so we plan to add it in the future. We'd love to support your needs however we can.

Thank you for asking!

Zak • May 8 '21

Hi Tyler,

I just chanced on this and I must say it's a really great article.

Userfront seems really useful for most of the common use cases. I have not yet had time to delve deeply into the docs but I was wondering if it's possible to customise the auth forms that's provided by Userfront or perhaps integrate with your own custom forms?

Thanks

Tyler Warnock • May 10 '21 • Edited

Thanks @codedpills , and yes you can build your own forms using the Userfront Core JS library (it's how the toolkit forms are built). We'll have a how-to about that shortly, and I'll let you know 👍

Marcolino • May 5 '21

But, according to Userfront terms of use, will I really own my users authentication data? And what if Userfront should fail, or be sold to some Micro$oft? Is it possible - at least in principle - to host a copy of Userfront on premises?

Tyler Warnock • May 5 '21

Thanks @marcolino for asking!

We also don't like vendor lock in, so we made it easy to export your user data to CSV, and, for things like SSO, to set the auth up with your own client IDs and secrets. That way if your needs change, you can always migrate.

We don't currently offer it on premises, as much of our value comes from keeping things up to date automatically for you. That said, if there is demand for it in the future, we are open to it.

Francisco • May 4 '21

Awesome!! Thanks a lot for the guide.

Tyler Warnock • May 4 '21

Thank you @fmontenegro0510 !

kennymanman • May 11 '21

Hey, want to try using userfront with an app and webpage. I'm new to backend and wanted to know how to gain access to a specific page that isnt in the navbar and also if i should use the frontend or backend forms to login customers and display their specific information.

Tyler Warnock • May 11 '21

Hi @kennymanman , a user is considered "logged in" if they have a JWT access token. So in general you have 2 options: check for the token in the browser or check for the token on the server.

If you check in the browser, you don't need a backend, but a savvy user could disable JavaScript (which would disable your check), and still view the page. So this approach should only be used for things that aren't sensitive.

If you check on your server, you can choose to never send the page in the first place, so a user couldn't view the page. The downside of this is of course that you need to have a backend server.

Do you have a sense for which one you would want? If it's the latter, what tech stack would you use for the backend?