R&D: Single sign-on / external authorization services

[hancush]

We're plugging our suite of BGA news apps into single sign-on provider Auth0. More broadly, it's nice when you can leverage an existing account to log into new services. Log thoughts on Auth0, as well as any other external authorization services, here.

N.b., @jeancochrane actually kicked off this convo with "Four Dealbreakers in Netlify Identity", out of #6.

[hancush]

Auth0

First impressions

Auth0 is a serverless identity management platform that allows users to maintain their own central user store or leverage social login, all from a pretty attractive UI.

Pros

• Quickstart documentation for integration with a number of common web frameworks, including Django and React (related to #6, specifically authentication with static apps).
• Nice admin user interface, in particular access to logs. This is really helpful for debugging failed login requests during development. Also notable: you can toggle on social identity providers.
• Options galore. It seems possible to implement whatever authentication flow you want, much of it from the Auth0 interface. I like that increased flexibility does not come with a corresponding increase in custom code. This also makes it easy for us to delegate configuration power to our clients, rather than having to manage it ourselves.
• Auth0 provides a customizable login UI, email verification, password reset, and all the emails in between. It's awesome to breeze past these previously time-consuming tasks.
• Auth0 has an open source program whereby developers can have free access to all Auth0 features if they include the Auth0 badge on their site.
• For non-OSS projects, there is a free tier with support for 7k users, and up to two social identify providers, although it appears that this plan is only available on a trial basis. The Developer plan starts as low as $13/month for 1k active users.
• While BGA didn't set up separate staging and production environments, this appears to be an option in Auth0.

Cons

• Options galore. The glut of options means it might be tough to hand off configuration to some clients.
• Since so many of the options are configured in the UI, we'd have to deviate some from our infrastructure as code paradigm.

I'm sure more things will shake out as we continue to develop with Auth0, but I have to say, I'm impressed at how little time it took to get rolling.

@jeancochrane, you mentioned you've had experience with Auth0, as well. It'd be great to get your thoughts on this, or any other services on your radar.

[hancush]

A brief update on the Auth0 thread: I stand by Auth0 being a nice tool for greenfield projects. It's pretty simple to set up and configure, and it offers a lot of functionality (including social authentication, e.g., via Google) out of the box. If you don't mind their interface, and you don't need to migrate users, Auth0 is a solid option.

However, integrating Auth0 with a legacy user store has proven quite difficult to achieve. There are several options for doing so:

• Bulk migration. Auth0 offers the option of loading in a dump of users from a legacy database, but passwords do not come with. Users must reset their passwords upon first login, however the built-in Lock interface does not offer any helpful prompts to that end, so more likely, they will have to try to log in unsuccessfully several times. There is the option to send bulk emails to notify users of the password reset, however it is not possible to configure a redirect URL for login success, so the user is just stuck on the Lock screen once they've done so. There's a thread on all this here: https://community.auth0.com/t/user-bulk-import-first-login-doesnt-trigger-password-set-reset/21091/7
• Trickle migration. This option entails granting Auth0 read access to your legacy user store, and defining custom Node.js scripts that hook into login and get user operations, authenticate against the legacy user store, and migrate data for the authenticated users into Auth0. In theory, this works great, however it does not send password reset emails to legacy users and, worse, indicates that an email was sent in the user interface. Moreover, if one has a user store from one application, but would like to use Auth0 across multiple properties, each application must be configured to check logins against the legacy datastore.
• Legacy integration. This option requires everything in the trickle migration, plus additional Node.js scripts and write access to your legacy user store. This is because all user operations are performed against the legacy store.

More here: https://auth0.com/docs/connections/database/custom-db/templates

It's also worth noting that it's very difficult to debug the custom Node.js scripts. They provide a facility for testing the scripts in the dashboard, however it's difficult to get anything other than a red/green indicator – neither console.log nor debugger statements seem to have any effect.

So, at this point in time, I wouldn't consider it a great option where user migration is involved – unless you want to write custom code to circumvent the shortcomings of the trickle strategy, which quite defeats the purpose of leveraging an existing service, IMO.

Semi-unrelatedly, if we were to adopt a tool for SSO, social authentication is one of my hard requirements. It strikes me that we wouldn't have a migration problem if we'd allowed users to leverage an existing profile in the first place.

[smcalilly]

closed in favor of #240