Custom invite flow where user sets password (my backend creates user). How do I login the user after this?

Get Help
,
1

Hi.

Here’s the flow -

  1. Admin user invites user by email. My backend sends that user an email with a custom link.
  2. When that user navigates to the custom link, they’re presented with an option to set their name and password.
  3. Upon clicking Submit, an API call to my backend creates the user in Auth0 using management api, and does some additional operations, and returns the newly created user.

Here’s the issue -

At this point in the UI (react app using auth0-react library), I want to “log in” the user. I can generate a token for the user as well and send that over. However, it doesn’t seem like the auth0-react library has some way for me to set credentials. It seems the library only offers managed login.

So, given that I’ve successfully created the user in Auth0 and supplied the token in the response after a successful invite flow, how can I “log in” the user at this point?

I do NOT want to call auth0.loginWithRedirect because then the user has to re-enter their password again which they just created.

Please let me know if need more clarification. Thanks

3

:wave: @kdm :sunglasses:

During our dev_day event this year, we introduced a Lab detailing a mechanism for folks to implement invitation-based workflow using the out-of-the-box Auth0 Organizations feature. Primarily a feature supporting B2B SaaS, the Organizations capability in Auth0 can also be used to implement invites in a B2C context, and leverages much of the Auth0 platform functionality that comes as standard. It offers some alternative workflow that. right be more suitable to your use case, and for more detail, you can take a look at Implement an Invite Workflow With Auth0 Organizations

Hope this helps, and please feel free to provide feedback as we’re always looking to improve the functionality the platform offers :hugs:

1 Like
4

Thanks.

I did check out that (looks cool, will have to try it in the future) but I have this existing invite flow on our backend and this is the only blocker for me at the moment - just wondering if there is a quick solution here :pray:

I am using GitHub - auth0/auth0-react: Auth0 SDK for React Single Page Applications (SPA) and wondering if there’s some way to update the underlying Auth0 context with the auth token to login the user.

As I mentioned in my OP the user is created via management API and I can generate a token for the user on my backend.

Is there some way to set this token into the Auth0 context so that I can avoid having the user login after setting their password?

Please let me know. Thank you

5

Thanks for the response @kdm :sunglasses:

…just wondering if there is a quick solution here :pray:

Not really. There are also a number of reasons why I wouldn’t recommend the workflow you’re currently using either; let me see if I can break it down a little to provide a little more context :slightly_smiling_face:

  1. Admin user invites user by email. My backend sends that user an email with a custom link.
  2. When that user navigates to the custom link, they’re presented with an option to set their name and password.
  3. Upon clicking Submit, an API call to my backend creates the user in Auth0 using management api, and does some additional operations, and returns the newly created user.

Aside from the fact that in 1, above, you’re having to manage your own invite workflow - providing the likes of rate limiting, threat protection, invite expiry, etc., to mitigate/reduce the attack surface - it sounds like, in 2 and 3, you’re handling user credentials outside of the IdP (Auth0). Handling user credentials outside of the IdP goes against recommended security best practices, and for a number of different reasons. Classically, we typically recommend using the Password Reset workflow as described in the Send Email Invitations for Application Signup guidance we provide, however, that guidance still requires the user to interactively login (as described here).

As I mentioned in my OP the user is created via management API and I can generate a token for the user on my backend.

I’m curious as to how you’re doing this. If you’re doing this via a Resource Owner Password Flow, say, then arguably it’d be in a confidential client context; leastways, in this case, a confidential client that can safely handle user credentials. But as a React SPA, your application is not a confidential client, and best practice from a security perspective typically recommends avoiding using a token intended for a confidential client in a non-confidential client context.

Is there some way to set this token into the Auth0 context so that I can avoid having the user login after setting their password?

As far as I’m aware, there’s no way to achieve this. At least no way we support out-of-the-box or in a recommended security best practice fashion. Unfortunately, to provide something like this as a feature would open up the potential for token injection - which is an attack surface that one would definitely want to avoid (for obvious reasons).

I would urge you to take a look at the Implement an Invite Workflow With Auth0 Organizations as it will likely provide you with not only a ready-made solution, but will also mitigate against potential (security) issues down the line :sunglasses:

6

Thanks! I see. Appreciate the indepth response!

Looks like I will have to re-work some of the login and invite flow in the future then.

I thought I could use management api to create the user securely on my backend, and then the user can just login with their credentials via the managed flow, or custom UI using authentication API.

I was looking at JSDoc: Class: Redirect and wondering if there was something like loginWithCredentials that I could somehow use with the auth0-react.

Once user is logged in, the auth0-react client requests a token that is used to authenticate with the backend APIs. So that part is fine and works well. I didn’t choose the organization/member approach because I have very granular permissions that are best handled by my backend biz logic. It also ensures someone cannot access another organization’s data, etc. There is only 1 “admin” role, and the rest are custom roles that admins can create for various things and assign to users.

7

Yes, that does work, but as I say: (a) we recommend using the Password Reset flow as documented here - i.e. creating the user with a random password then putting said user through a scenario where they change their password in Auth0, not within your application, and (b) the user will still have to interactively login once that (classic) invite flow is complete - as described here. The Implement an Invite Workflow With Auth0 Organizations takes care of both of these for you: handling (a) whilst mitigating (b).

I was looking at JSDoc: Class: Redirect and wondering if there was something like loginWithCredentials that I could somehow use with the auth0-react.

That could get you a token, but as the documentation says, Logs in the user with username and password using the cross-origin authentication (/co/authenticate) flow. Cross-origin workflow can be extremely problematic - both in terms of configuration and in terms of use with various browsers; see our Cross-Origin Authentication Docs for more details - and so isn’t something we’d recommend using unless you absolutely have to. I also highly doubt it will work with the React SDK for the reasons I mentioned previously (i.e. vis-a-vis token injection).

I didn’t choose the organization/member approach because I have very granular permissions that are best handled by my backend biz logic.

You can certainly leverage Auth0 Actions extensibility to perform additional/supplemental Authorization - even going as far as calling your own Authorization policy engine. The documentation here has some examples you can reference. In fact, Okta also has the FGA product, which provides a “Relationship Based” access control mechanism out-of-the-box - something you can also host in-house using OpenFGA - rather than building your own implementation :grin:

It also ensures someone cannot access another organization’s data, etc.

Again, Auth0 Actions extensibility can help here depending on the use case scenario(s) in question :sunglasses:

:thinking: As I say, I would definitely recommend evaluating the Implement an Invite Workflow With Auth0 Organizations. However, depending on the current Auth0 subscription you have, I would also suggest potentially considering an engagement with Auth0 Professional Services as it sounds like you might have some fairly complex use cases you’re looking to address.

2 Likes
8

Thanks a lot for the details! :sweat_smile: lots for me to learn :smiley:

Appreciate your guidance!

2 Likes
9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.