Auth0 Home Blog Docs

Invite not-only application

#1

In here, we have the following flow :

  • A conversion funnel, where the user leaves an email
  • A customer space application (SPA), where the user can find back the information she sent in out conversion funnel

What we are trying to achieve is, when a user finishes our conversion funnel successfuly, to send an “invite email” on his email. With this email, we comes to an universal signin / signup form, and is given some permissions (and associated, securely (non-forgeable), with some data of our own, located both in our databases and CRM). If the user signin using a provider (or even a previous-made email/pwd account), the data is associated with him. If the user signups, the user is created and the same association occurs.

Last day, I was inviting my developer to Auth0, and I noticed that the Auth0 internal… auth0 flow, is exactly what we want. Think of it :

  • When you want to “invite some admin” to Auth0, you go here https://manage.auth0.com/#/tenant/admins
  • You type an email
  • The person receives an email with a link. This link is very similar to a /authorize one, but is augmented with a ?token=XXX (which is not a jwt). This token seems to be an associative-token
  • If the user signs in (or even signs up, I believe), his account is either created+granted-admin (signup) or just granted-admin (signin)

This behavior is pretty cool, I like to guess that Auth0 is using Auth0, and I’m trying to achieve the exact same behavior. So any information on how to accomplish this with a clever flow, a bunch of rules and I guess some external service ?

Thanks :slight_smile:

EDIT: some things to note :

  • We don’t want that app to be invite only. We want to keep auto-signupable feature
  • We need providers like Google and Facebook
  • We definately just need something exactly like Auth0 internal subscription (let user signup / social signin, and invite him to have specific role)
#2

Hi.

https://auth0.com/docs/design/creating-invite-only-applications should be what you are looking for, if I understood you correctly.

#3

Hey @JoseSantos,

Thanks for your reply.

I just realized that I said “not-only” in the title, but did not mention anything about it. I’m going to edit.

Invite-only is precisely what I don’t want, lemme clarify with an edition up there

#4

Hey.

Sorry, that was my bad. My eyes tricked me.

It seems to me that what you are really interested in is in the expirable/single use link mechanic, where you’d have control over the semantics of the token/ticket.

From the Management API, the only links you can obtain are for email verification (https://auth0.com/docs/api/management/v2#!/Tickets/post_email_verification) and password change (https://auth0.com/docs/api/management/v2#!/Tickets/post_password_change).

You can’t “configure” those links and both will send the user to an Auth0 controlled page where you don’t have many options for customization.

I have used in the past https://github.com/hueniverse/hawk#single-uri-authorization, which can get you a secure, expirable link with whatever semantics you decide. It does not have single-use semantics though (a sensible expiration can mitigate this limitation).

In terms of roles/permissions this could be done all in your side (via Management API for example) or in a rule, that runs on user login.
You might just add a role property to the user’s app_metadata or maybe even use something like the Authorization Extension (https://auth0.com/docs/extensions/authorization-extension/v2) or call out some external resource.

I hope that helps, if I didn’t misunderstand you again :sweat_smile:

Best regards

1 Like
#5

Thanks for clarifying, and thanks for trying to help :slight_smile:

Yes, and I’d like to avoid those kind of hacks. I usualy think that using the right tool for the right thing is often the only doctrine it’s worth following.

Yes. We’re not afraid to develop a micro-service for this kind of logic, neither to code some complex auth0 rules to achieve our desired flow :slight_smile:

Though, I’m struggling to find any design advice for this kind of flow, and I couldn’t find some great rules or diagrams as starting points for this.

When I think about it, as I said, the internal auth0 behavior (when inviting some admin to your auth0 tenant) is very precisely and effectively what I need… it’s such a shame that this behavior is not documented, as they managed to actualy implement it on their own stack.

EDIT:

I’m talking here of “when” to bind this micro-service / rule to the flow ? Where ? How ? Is there any pro/cons to coding an external microservice that acts with Management API and sends the email, versus coding a rule ?

#6

I think it is a matter of trade-offs, like most things in our business :wink:

As you probably know you can do virtually “anything” with rules, given rules are arbitrary javascript code with a huge number of available modules (https://auth0-extensions.github.io/canirequire/). Hooks are the next evolution of rules and have the same/similar semantics, the current difference mostly being the extensibility points - at what point does the code run in the Auth0 pipeline.

Given the great flexibility of rules/hooks I’d say that mostly the limitation might be the “reduced” number of extension points. Rules run at login, while Hooks currently run at 3 defined points - client credentials exchange, pre user registration and post user registration. That gives you 4 discrete extensibility points where your code will run.

Depending on the control/flexibility you want/need, that will inform your decision regarding the usage of rules/hooks vs your own service that interacts with Auth0. There is also the matter of code locality - it might make sense that you keep your “business logic” close together as opposed to spread between a handful of rules and your own service.

I can share the “invite flow” we implement, it might be useful even if only to raise more questions or as an example of what you might not want to do :stuck_out_tongue:.

An “invitation” in our systems is handled by an internal service that interacts with Auth0’s Management API. It goes something like this:

  1. Lookup the user by the invitation recipient email
  2. If the user already exists we just run some business logic to “finalize” the invitation (setup internal associations, trigger welcome email, etc)
  3. If the user does not exist, we create the user via the Management API with a temp password and a status: "invited" flag on the user profile app_metadata.
  4. We call https://auth0.com/docs/api/management/v2#!/Tickets/post_password_change to get a password change ticket to add to our custom invitation email, welcoming the user and prompting them to set a password for their newly created account.
  5. On first login, a rule removes the status: "invited" flag and sets up some additional app_metadata.

On another note, recently Auth0 also added RBAC functionality to their core product (https://auth0.com/docs/authorization/concepts/rbac) which looks pretty cool. I’ll definitely be looking into how we might offload access control management to Auth0 :wink: