Benefits of using Auth0 with a Parse Server/React Native application?

Loading...

Benefits of using Auth0 with a Parse Server/React Native application?

I'm wondering about additional complexities involved in integrating with Auth0 vs plenty of available code for password complexity rules, UI etc. including using snowflake starter app, for authentication/user creation with open source parse server.
I am sure plenty of people have thought about this and was wondering what the consensus is? Requirement to keep profile/email in sync, relying on 3rd party, inability to customize view and I am sure many other issues.
At first I thought this is great, I would not need to worry about a lot of things, yet there are a lot of other things to worry about and not being able to customize.
What are the most convincing "PRO" answers?

Solutions/Answers:

Answer 1:

Disclosure: I’m an Auth0 engineer.


TL;DR: I can talk about the pros and cons, but the definitive answer needs to be provided by you.

A bit about Auth0

Auth0 supports the authentication protocols in most widespread use (OAuth2/OIDC, SAML and WS-Federation) so integration into custom software that speaks or can be made to speak by available libraries is relatively easy and friction free. Sidenote, Parse Server does seem to support integration with OAuth compliant identity providers.

It can be used as a standalone identity provider where your users register and authenticate with username/password credentials specific to your application, but it can also integrate with a lot of downstream identity providers like for example Google, GitHub and Twitter. This makes it really easy to enable different methods of authenticating users just by configuration instead of having to directly talk to each individual provider and have to deal with their implementation discrepancies.

Finally, it provides enough extensibility points for you to still have significant degree of control on the authentication experience, for example:

Of course, no matter how many extension points there’s always some stuff that you will not be able to control. This can be seen as bad, but sometimes it’s actually a good thing. Depends on the perspective and your specific requirements.

Comparison – Roll your own (RYO) vs Third-party service

On one side you’ll have:

  • cost of acquisition of the service
  • cost of integration of the service with your product

On the other side you’ll have:

  • cost of implementing the features you need
  • cost of ownership of those features
  • cost of integration of the new features in your product

In both cases you’ll need some integration work in order to make all the parts fit no matter who created the parts. You could argue that if you are the author of everything it will be easier to fit a square peg in a round hole so lets say RYO wins by a small margin on that point.

It then all comes to comparing cost of acquisition versus the cost of implementation and ownership. I can’t answer that one, but the cost of acquisition is generally easy to calculate while the cost of implementing software is very hard to predict; on top of that owning a custom authentication solution also has a heavy toll… you know what they say, no one ever got fired by buying IBM. I won’t go that further, but it’s safe to say it’s easier to find yourself in a pickle if you roll your own security. 🙂

Conclusions

Go through the Auth0 trial, play with it and see what it has to offer and how that matches your requirements.

If you find something you’re not able to accomplish leave a question here tagged auth0 or on Auth0 Forums.

References

Loading...