Stop using the simple authentication method for Particle products?

#1

Hi,

Recently there’s been a Deprecation of Sending Password Reset Emails email sent from Particle.

I am wondering if this method here:

image
image.png1000×780 13.2 KB

has any potential use in real life, considering that once a customer is created there is no way to reset their password. Granted, one can set their password, but for that one would need the auth key of the customer that may not be available anymore (if the customer reinstalled my product’s app, for instance).

Consider that one of the advantages of simple auth was to NOT have another mechanism or cloud to manage customer accounts, from here:
Simple auth is ideal for getting a Particle product up-and-running quickly. Without needing to build your own back-end, development time to creating an app to work with a Particle device is greatly reduced

Now the recommendation from Particle is to switch to two-legged auth, which requires you to have and manage your own backend.

Am I wrong to think that there is no use anymore for the simple auth flow?

Am I wrong to think that the documentation should warn all future Particle product creators that simple auth has this major limitation of one not being able to reset the product customers’ passwords?

Please help me understand a bit more all this.
Thanks!
Gustavo.

Answer from @jeiden on a bug someone opened already:

One related thread is here.

fyi @rlysens @bloukingfisher @jeiden @will @jvanier @mstanley

#2

Hi @gusgonnet

I suspect Jeff’s email might have contained a mistake.
We are actually deprecating POST /v1/products/:productIdOrSlug/customers/reset_password' and POST /v1/orgs/:orgIdOrSlug/customers/reset_password (those endpoint use the SMTP settings in an org which we are removing).

You should still be able to reset a customer password directly via authenticated POST /v1/password just without SMTP/Particle sending email on your behalf. So I think simple auth is still useful as long as you’re hosting your own “reset your password” webpage and email sending mechanism that’ll trigger that request.

Makes sense?

#3

I agree with @gusgonnet that this move makes it much harder, instead of simpler, to bring a product to market. Much of the attraction of Particle is the infrastructure maintained by Particle.

@ido any support or documentation from Particle to make this “create your own website flow” thing easier? Particle provides this repository for password reset web page…but it doesn’t help as it requires to validate a code in the email that presumably use to come from your system. Maybe the team can expose the other end of this code that generates the code/email for resetting?

Another question now that you remind me we can still use the /v/password endpoint, how exactly does that work with “sub”-customers? Under simple Auth, an email address with Product X and the same email address with Product Y - will the password be updated under both products?

#4

Hi @ido, thank you for your answer.
Would you mind elaborating on how one can do such a thing? I get it that no email is sent, so how is the reset password link provided to the user?
You say authenticated POST. But authenticated with what, if the user has lost their password?

In case it helps, I am using the Particle API JS.

Thank you!
Gustavo.

#5

@ido

Can elaborate on why the decision for not supporting the SMTP option?

Just wanted to add support for @gusgonnet & @bloukingfisher statements.

#6

@oraclerouter, @gusgonnet I forgot about an email exchange with Jeff on this and his answer (I assume it is OK to share):

“I certainly agree with you that it’s our goal to try and solve as many of the challenges as possible to help product creators build and deploy connected products. In this particular case, very few companies leveraging the platform were using this feature and another major improvement to the product is dependent on taking action here. We’ve found an overwhelming majority of product creators bringing IoT products to market prefer to handle their own user authentication / credentials.”

Maybe @ido can still share more perspective, but more importantly a suggest or support a bridging solution. Simple Auth is still strongly promoted and commonly available throughout the Particle ecosystem. I think therefor it should still be a supported solution with some kind of tool or code base for product creators to leverage, in this case with password resets.

#7

@bloukingfisher thanks for sharing this convo with Jeff. This is indeed correct, I just re-verified that we have a very low number of customers actually using this feature.

However, I am acknowledging that all of the concerns and arguments raised here are very valid.
I’d like to provide clearer instructions on the recommended (and easiest) path forward here and need few days for that, please bear with me. I’ll keep this thread on my radar and provide more info soon.

Thanks and apologies for the confusion this matter has created.

#8

Thank you @ido and looking forward to learning the proper way out of this.
Thanks!
Gustavo.

#9

Hi folks,

I’d like to provide some insight on the path forward, how it should be done:

Previous process:

  1. Customer loses access, clicks “forgot password” on your mobile/frontend app
  2. App hits unauthenticated POST /v1/products/:id/customers/reset_password
  3. This triggers an email to the customer (if SMTP settings were configured) that contains a link to reset his password (behind the scenes a short-lived reset password token is created)
  4. Email links to Particle’s SSO app that shows the “set new password”, verifies the said token, customer types in new password and frontend hits POST /v1/password with token and new password (behind the scenes).
  5. Customer password is reset.

New process:

  1. Customer loses access, clicks “forgot password” on your mobile/frontend app
  2. App hits an endpoint on your backend [the backend app should “know”: (a) Your Particle access_token - the one you used to create that product, (b) Optionally, list of valid customer emails]
  3. This triggers an email to the customer sent from your backend. Btw, email can now have your brand logo/colors etc. Email contains link to reset his password (behind the scenes a short-lived reset password token is created and stored in your backend db)
  4. Email links to your hosted brand-themed webpage that shows the “set new password”, verifies the said token, customer types in new password and frontend hits an endpoint on your backend with the new password.
  5. Backend hits Particle’s API existing authenticated PUT /v1/products/:id/customers/:customerEmail {password: <new_password>, access_token: <your_token>}.
  6. Customer password is reset.

Thanks to this thread - we’re hard at work creating a full working example for the new process, can’t say when it’ll be available but I can say it will be a relatively simple backend/frontend app, hosted on a free hosting service. I won’t suggest waiting for that and would encourage you to start implementing this solution on your side.

I know Jeff’s email specified that the deprecation will occur on an earlier date but I can confirm it will happen, in practice, through the end of September.

Let me know if you have questions.

Cheers

#10

Great info @ido. I’ll digest all this, code something and report back or ask more questions.
Thank you!
Gustavo.

#11

Thank you @ido it is much appreciated. I’d be happy with a relatively simple solution.

Since it’s beyond my expertise, I don’t know if this suggestion is feasible: If two-legged is the preferred method for product creators, perhaps it’s better to develop a relatively simple integration solution focused on that instead. Something like “if product_mode = true and two_legged = true” then invoke AuthO or Firebase process. It can be designed for a specific provider with instructions for creating and setting up an account if you wish to leverage the solution.

My partner developer is estimating for us to build two-legged ourselves will take 8-10 days development time plus testing time. So that doesn’t sound very simple, but then I assume someone more familiar with Particle and two-legged may take a fraction of the time. Underscoring the point of the value of Particle supporting an off the shelf solution that product creators can choose to plug into if they don’t have large teams and desires to build their own preferred solution.

#12

@ido
Do you think is wise to add a WARNING to the simple auth docs for future and current product creators that the simple auth is not so simple anymore? In fact, this paragraph below seems to be invalid now:

Consider that when building a flow, the last thing one can test (or perhaps it was only my case) is the email reset.
You start implementing things from the beginning and then later find out the hard way that you really need your own back end (simple yes, but you still need it).

If you want I can propose a pull request so people know today about this limitation today, and don’t need to wait until the end of september or when the implementation you are proposing is done.
Thanks
Gustavo.

#13

@ido @jeiden
I cannot say what was the thought process here, but one thing that I imagine I would do to see if a feature is being used or not is go check how many times was it used in the past month, year and then make a decision.

However, one thing that has to be put on the table here as well is: what happens if the feature was used 5 times by 5 customers last year BUT the feature is a recovery mechanism (like a password reset)?
Why do I say this? A password reset is not something you do every day, week, month, or even year.
Maybe when Amazon forces me every 6 months I begrudgingly change the password, or when my employer requests this change every 3 months, well, I have no choice.

But we are talking an IoT product here. How many times would a user want to change their password on their garage opener? On their spa? Zero maybe?
So, if the metric of hits per yea was the main deciding point, I would add, for next time, the dimension of how many times it is supposed to be used by the end customers.

My moral of the story is this: I can’t deprecate a recovery mechanism based only on it NOT being used too much in the past years since at the end is only that, a recovery or emergency mechanism that one would need to get out of a situation in case of an emergency.

A cheap analogy comes to mind: imagine a school bus removing the emergency exit because it was not used in the last 5 years.

You can now safely ignore this. I felt like writing it not to complain but in the hopes to offer another view at this and perhaps help in future decisions.

I’m already in the middle of implementing the back end changes needed for this and it is going to look even better than before, BUT at the cost of more work.

I’ll tell you why is better than before for future reference:

1- I can now control the look and feel of the email the user receives.
2- The product I’m working with in this case has wifi and cellular options. Having a customer created in both (a wifi Particle cloud product for the photons, a cellular one for the Electrons), meant that for the password reset flow the customer would receive two identical password reset emails as I explain on this topic.

All the best!
Gustavo.
PS: I am using the Firebase Auth feature to implement this on my side.

#14

@gusgonnet I would suggest go ahead and do it anyway…though it seems /docs pull requests are not as quickly merged as you’d think looking at the open list. Although, I see the issue that this is more of a positioning decision point for Particle to frame how they want to approach it than a simple “correction” to the docs.

@gusgonnet I’d be curious as to your take on the feasibility of having a Firebase integration available with a flag set…or maybe one of your terrific project sample writeups you do!

#15

what does the flag there mean?

thanks
I like that, I can share what I did in a quick post here in the community and then in a better thought out write up.

#16

I mean adding code functionality to the SDK/mobile apps that product creators can activate through a flag, e.g. pseudo-code:
use_two_legged = true //product creators set to 'true' if you want to use the suggested two-legged method with Firebase