Two products, same customer: can two password reset emails be avoided?

Hi guys, Hi @jeiden

I am working on a device that can have electrons and photons as part of the fleet.
Since the device can use either particles, I think I have to create two products, one for the photons and one for the electrons, since one product supports only one type of device, understandably so.

So, if my understanding is correct, when the user signs up for the system, I intend to create a new customer in both products.
Hence, if the user forgets its password, I will need to reset their password in both products.
This will produce two emails with instructions to reset the password, which may totally confuse the user and I will need to tell them to not to forget to address both emails.

It could be that this stems from the fact that I’m using the one legged auth flow…
Am I reading this scenario correctly?

If you want to hide the complexity of your ‘product’ being powered by either an electron or a photon why don’t you claim the devices on a single user account (the corporation/company account) and then have a web app that subscribes to the 2 product event streams. The web app then handles all the use of the access tokens to subscribe to and call functions on either product. The end user customer just needs a password to access the web app and you can manage that through normal processes. You can implement 2FA - with a SMS code if required.


Hi armor,
I’m not clear on what you propose, please let me ask you few questions.

yes, I can claim the devices with the same account, I mean, same credentials (same email/password). However, since one device is powered by an electron and one device is powered by a photon, they cannot belong to the same product (by Particle product limitation), hence, I will need to create two products.
In each of those two products, I will create the same customer (with same credentials).
My app will log in in both and get an access token for each account in each product and send the right API calls.
This I can manage without the user ever noticing and I’m alright with that.

However, when the user resets their password and my app calls the API for reset password on both products, they will inevitably receive two emails with reset password instructions, which may lead to confusion, or simply one email not being looked at. This is an undesired situation.


Could not figure out what you meant here.


I think you need to study the differences between owner (claimed by) and product bearer access key when using the cloud API a little bit more. The reasons or problems are exactly why we didn’t have access token related to the end customer account?

I have about 8 products now. The product is unique to the Particle device type, the circuit board it sits in and the application code. The web app recognises each product and when subscribing to a product event stream or to make a function call uses the correct product access token. These access tokens are managed centrally.

All devices are claimed by members of the team for each of the products. Each of the team has a Particle login and password and has been authorised for each product. For a good number of the total population of devices (circa 600) this is just one owner but as product provisioning has been handed to the production team for all new devices this is changing.

End user customers only interact with the web app and never with Particle Cloud. They login to the web app and can only see data and control the devices they are authorised to (by the web app security).

Hi armor,
From what you describe, I think you are running a two leg auth scenario, and my question pertains to a one legged scenario. Could that be? thanks!

good advise, will do that too

Correct - using a Oauth server - two leg auth scenario. It took me a while to understand.:wink:

1 Like

i would call each device(product) within the system a descriptive name which the user could recognize as a distinct entity. for example, frick and frack (but of course, you do a better job at naming) and within the user guide of your system explain the system is built on frick and frack. never done products for myself but i would imagine that you could name the 2 products frick and frack within the particle auditing system so that when the emails are sent one mentions reset of frick password and the other mentions reset of frack password. this make any sense?
edit: i’d think the 2 reset emails would be a necessity but not sure of particles config so i can’t really answer your posts question just offer somewhat of a workaround.

Thank you Douglas!

I think this is interesting. Perhaps an improvement one can propose to Particle. Let’s go:

@jeiden Do you think the reset password emails can include a product name by any chance?