Implementation Advice to avoid pitfalls

Get Help
, , ,
1

Hi all and thanks in advance,

We’re about to implement Auth0 for our existing Drupal 7 site. To date we’ve only got this one site requiring authorization. Our near future plans are to move to a different framework, (possibly Drupal 9). For starters we’ll want authentication, and then SLO, MFA.

We’ve found the D7 branch of Auth0’s Drupal module and used that as a starting point to get a proof of concept with a Auth0 dev account. Now we’re about to embark on creating the real thing.

Our first challenge is to convert all our existing site users’ login procedure to using Auth0.

We’d like to start using Auth0’s user id for all other SaaS that we’ll incorporate.

We want to force users to create a new password, as the existing site hasn’t had any password rules. Does anyone have suggestions about these 2 approaches?

  1. Import all existing user’s info into Auth0 ahead of time
    or
  2. Send each user’s info to Auth0 the first time they attempt to login after we’ve started using Auth0

In addition, we’re considering using Auth0 as our one source of truth for user info.We’d user_metadata and app_metadata to store something like 25 properties for each user. That would mean querying Auth0 for user info for other SaaS we use (i.e. analytics, billing) Any advice on the practicality of this would be greatly appreciated.

Finally, if there’s any advice on common pitfalls of Auth0 integration, it would be gratefully received.

~Reed

2

Hi @reed

First: both approaches work. I recommend bulk importing if possible, as it means you don’t have to support the legacy IDP for an undetermined amount of time.

The password change requirement can be implemented in a variety of ways, the simplest (but not very friendly) is to bulk import without a password. Users would have to reset their password to login, and the new password would met the constraints.

Auth0 is not intended as a general purpose user info DB. Look at the properties and determine if they are central to Identity/Access. If they are, they belong in Auth0. If they are not, the do not. Analytics and Billing do not sound like they are central.

John

1 Like
3

Thanks John, very helpful.

1 Like
4

We are here for you Reed!