Dashboard oauth client and JS SDK for organizations

From Particle documentation:


Soon (Late August 2015) you will be able to go to the Particle dashboard and click “Create app” to create a client ID and secret. (Ping @zachary in the forum if we fall behind on this estimate or you just want to say how much you want this feature!)

@zachary and the team - when can we expect this functionality ?
Of course, everyone wants this funtionality VERY much - dashbord is not fully usable without it…

And another question - when will the JS SDK support creating users for the organizations ?
Please, don’t make it wait in a queue after IOS and Android, this is a killer feature, doing it in a web app is much much easier than in a native app ! (and allows building a hybrid app with phonegap/cordova as well).

Everyone interested in JS SDK for organizations - please show your support in the forum !



Thanks for the bump! We just started a sprint laser-focused on the Electron. I’ll recommend that these organization-specific features get prioritized when we plan sprint 44 (9/17–9/30). As the docs say right below that:

Right now you can make an API call to create an create an OAuth client using the instructions in our API reference.

Hint: POST /v1/clients

Creating customers within organizations is also documented in the API reference:

I strongly recommend that someone in the community add these API calls to the open source sparkjs repo. Unlike a lot of the Electron work, this is something you all can immediately help with! Seize the day!


@zachary, thanks for the info. I know of course it can be done via API, the only problem I see here is some lack of consequence in my opinion:

  • dashboard without option to create oauth clients, stuck in 4.1 firmware
  • http API to create oauth clients and customers
  • javascript SDK not aware of organizations stuff, working in a browser
  • separate javascript library for SoftAP, NodeJS only
  • community member created SoftAP javascript example, working in browser
  • bug in 4.4 firmware

What I’m looking for, is a hybrid (phonegap/cordova) custom app for my product.
To be honest - based on above list, I don’t see a full solution available today.
What I hope for, is an integrated JS SDK, allowing for all current API operations (with organizations stuff), plus ability to setup a device WiFi credentials, plus device claiming. So, basically everything that is available from IOS and ANDROID SDK.

I’d also like to consult the security issue:

NEVER expose the client secret to a browser.

Is it really such a danger, with the scope limited to

create_customer ?

If the app I create already allows for creating customer accounts, what is the risk of exposing oauth credentials (allowing just for creating customer accounts ?) Am I missing something here ?

Understood. We at :particle: and those who contribute to our open source repos will keep working toward a unified solution. :bow:

Do you have a PhoneGap/Cordova app already for the other parts of the app? What will the app be used for besides device setup?

If the app never needs to subscribe to events, call functions, read variables, check the list of devices, claim devices, etc., then absolutely a client that can only create customers will work fine, and the security risk of exposed credentials is just the creation of bogus customers. If that’s low risk to you, then you’re making an informed decision. :+1:

Nice to hear that !

About the app - yes, I have it (almost) ready, and yes, it calls functions, reads variables, and checks the list of devices.
Still, as I understand it (correct me if I’m wrong) - oauth credentials allow ONLY for creating customers.
(About bogus customers - if I publish the app allowing for customer creation, user can create hundreds of bogus customers with just this app, so that’s an informed decision anyway)
So, the user uses the app to create a customer, than logs in with this customer account, than he can claim his product, and use functions, variables etc.
He can’t just log-in with the oauth credentials, as those are scoped to just create customers, right (or can he) ?

If you are calling functions from the app, then you are using an OAuth client that has full access, not one that may only create customers. A client gets you an access token; an access token is always associated with a client. If the secret for this client is exposed, then she who has it can control all your customers’ products.

For development, just to make life easy, we recommend using particle as the client ID and particle as the client secret. Are you using that by any chance? If so, your production app needs a different client.

Which authentication method are you using?

For the development, I’m using “regular” particle account, created before the “organizations revolution”.

Let me explain how I understand the whole stuff:

  • I use my particle credentials (team member within an organizations) to create OAuth credentials (ID plus secret).
  • OAuth credentials allow ONLY for creating customers (scope=create_customer). I just checked it out. It’s impossible to login to Particle Cloud using OAuth credentials. It’s also impossible to login to Particle Dashboard (simple reason this time, no “@” in username).
  • With OAuth, my app will create customers.
  • Then, customer will login (app will login him automatically first time) with his new customer credentials, claim his device, and use it’s functions, variables etc.

So, once again, the only risk in this scenario, is that user decodes the app, and extracts the OAuth credentials (ID plus secret), but, this can not be used to anything else, than creating customers… so this is harmless, app allows for creating customer accounts anyway.

Please confirm that I understand the whole process correctly, thanks.

I am very interested in JS SDK for organizations.

Hey @kefir135,

Just wanted to chime in here, as an engineer working on organization-related tools here @ Particle.

We discussed prioritizing the OAuth client UI in the dashboard for this sprint. However, there were other extremely high-priority items that had to be put in front of this development. While likely not a part of this sprint, when returning to new feature development for the device management dashboard, building this page will be one of the first tasks to get done. Thanks for pinging us on this!

As far as the JS SDK, @nexxy is working on an MVP of browser-based setup this sprint as her top priority that we are aiming to ship at the end of the sprint. It is worth mentioning, however, that the initial version will likely only support user-based setup, and organization support will likely be a follow-on.

I know this sometimes may be a bit frustrating to wait, but trust us that we hear you and want to deliver on these ASAP. We are still a relatively small team and work very hard to prioritize to the best of our ability. Hang with us!

1 Like

Hey @jeiden, thanks for the update, sure will wait patiently !

Hey guys, super keen to hear of any progress here as well as I’m currently building a web app for customer account creation, WiFi setup and claiming etc.
I’ve used the work from Nexxy etc. to create the SoftAP side of things but I’m a bit lost now as to where to go in terms of organisational customer claiming etc.
So basically the same as what @kefir135 is after by the sound of it. I take it this is still on the to do list? Thanks for all the amazing work!

@jeiden , @nexxy

any progress with:

OAuth client for the dashboard ?
Organizations support in browser based setup / JS SDK ?

Months pass one after another, and seems like you still have another priorities guys :frowning:

Look as this thread:

It really looks like



Hi @kefir135

I’m battling with this myself at the moment but I am making some progress.
As far as I know there still isn’t an option to create an OAuth client in the dashboard, however it can be be done quite easily via curl and only needs to be done once per app so it’s not a biggy.

If understand correctly, you’re still trying to create a customer via OAuth client? If so, take a look at my thread here, with the help of the Particle team I’ve just managed to submit an HTML form to create a customer for my organisation using my client_id and then redirect them to my setup page.

Still a bit of work to go but getting there!


Hey @kefir135,

Thanks for checking back in on this. I totally understand your frustration with this, and am very sorry. As someone who cares passionately for the product creator experience and am familiar with all of its complexities, I know it’s tough to be promised things and have us not deliver in a timely fashion. For this I apologize, but hopefully I can use this post to unblock you in any way possible and provide some transparency.

First, I think it is worth pointing out that while neither of the things you mentioned have been completed yet (OAuth client UI on the dashboard, and org support in our JS SDKs), it is 100% possible right now to start building a browser-based device setup app as @G65434_2 has alluded to and is working on in his thread.

  • OAuth clients can be created via a POST request using cURL. In-depth instructions on this can be found both in the guide on authentication and security and in the reference docs. Adding the UI on the dashboard will certainly be helpful and simplify this step, but is really only a view layer on top of existing API endpoints
  • The API endpoints for creating a customer in a JS context are in place. This involves using the implicit grant flow. This is discussed in detail in @G65434_2’s thread
  • Once this is done, you can start the device setup process with our SoftAP setup Library

Soon, this whole process will be streamlined and wrapped up nicely in Particle JS, but the “guts” are all there for you to work with.

Also, just to shed a little light on our priorities and why things may be moving slower than we all would like on this front: We are still a small startup with a small engineering team (~10) that is taking on a mountain of different tasks. Right now, a very high percentage of our engineering efforts is going towards shipping the Electron on-time and in a way that we’re proud of. There is a ton that makes shipping the Electron more complex than the Photon, most notably shifting to an environment where viewing, managing, and conserving cellular data usage (the user pays for this data) becomes a priority unlike Wi-Fi (data is “free” and not necessary to manage). Unfortunately, due to the size of our team, this forces us to prioritize our efforts and sometimes de-prioritize other things we know we need to build.

In addition, @nexxy has recently chosen to move on from Particle (we will miss her but are excited for her next endeavor!) which leaves a large hole with making progress on open-source JS projects. The combination of these two factors is the reason why these tasks have not been completed.

I say these things not to shed responsibility, but to be open and transparent as possible to you so we can better support one another moving forward. Once the Electron has shipped and/or replacing our JS engineer happens, I’m very confident that much of our engineering efforts can return to the product creator experience. As always, we encourage ongoing feedback and dialogue to make sure that we are equipping you with the tools to build your connected product (after all, that’s why we’re all here isn’t it :smile: ?).

Again, I apologize for your frustration and hope this provided some clarity/unblocking goodness.



Thanks so much @jeiden for keeping an eye on this thread, and thank you @kefir135 for keeping us on our toes.

Jeff has explained the current priorities at :particle: very well, but I just wanted to add my additional assurance with regard to timelines.

  • Through January we’ll be focused on shipping the Electron.
  • Into February we’ll be fixing any issues that arise once 10,000 Electrons are in hands of backers in dozens of countries around the world
  • Once we hit March 1st, the whole company will shift focus to Stability.

Stability means many things in terms of our potential daily tasks and tactical priorities, but among them is ensuring that product creators have not just the bare minimum tools they need (e.g., API endpoints for OAuth client & customer creation), but the best end-to-end experience surrounding those tools as well.

Another big focus when we turn to stability will be to create a stable firmware branch for long-term support, also as a tool for product creators who are paying us for support. All development will still continue open source in GitHub, so all bleeding edge changes will continue to be available to those who want them. However, product creators especially have a need for firmware with well understood and stable behavior, where new features don’t unexpectedly add bugs, which of course happens on the main development branch of any large software project.

Thanks for caring enough to push us to be better. Big announcements will keep on coming over the next few months. Big things are happening at Particle. All of you who have a stake in our success can rest easy; things are going very well. We’re setting ourselves up for some exciting sustainable growth.