Methods best to handle access tokens in apps

Since I need to put out a product ASAP and the Photon is backed ordered to May, I’m moving forward with the CORE.

Ok lets say I already claimed the Cores, flashed the firmware, and cleared the WIFI credentials before shipping the product out to the customer, now what do I do with the access tokens. From my understanding the tokens are just used to access the SparkCloud to a particular Core ID. Right?

So here’s the scenario. The customer could use a phone App I wrote installed from the Google store or download a webpage I wrote to run on their server to access their Core product. However, the App or the webpage needs to know the Cores ID and access token to communicate to the product.

How should this be done? Presently, I hard coded the information in my prototype.

Since I don’t want to hard code the ID or token in the phone App or webpage, how should we code these things to obtain access? I read some place about using PHP, but it did not explain what to do with it.

Please explain, step by step so I can carry it out.

Also when it comes time to refresh the access tokens,how should it be implemented?

Thanks again for helping.
This is my first wireless product.

From my understanding, every user should have there own cloud account, if the app is interacting directly with the CORE Server. The Token is simply a ShortCut for your Cloud Account.
Otherwise every customer can interact with any other core (assigned to the same cloud account)

The user will not know about the IDs or tokens. I’m assuming I can write a PHP script to give the users the appropriate access. If it’s an Andriod or webpage, it would request is from the PHP script and when granted, it will get the ID and token to communicate over the Cloud.
I’m still waiting for a response.


I had the same problem.
you have to know that the accesstoken expires in ~30 days.

The customer should sign up his own cloud account.

Then you have to create an mechanism in your app, which creates a new token by typing the account creditials and stores it for ~ 25 days.


Having my users sign up separately with Spark (or even care that I’m using a Spark product) is a terrible solution… that throws usability out the window. I want my product to be as simple to setup and run as possible. This means making it trivial to create an account in my mobile app, and my web service handling all the access token interactions behind the scenes.

Can anyone from the Spark team the “expected” way that product developers would manage our user’s access tokens?

Are things changing or getting easier on this front with the new “fleet management” features?


In my own opinion (not necessarily Spark’s) the Spark Cloud and Spark Access Tokens aren’t supposed to be used by a user directly (in your situation). In my mind you, as the app owner, would have to come up with your own way to authenticate the user in the app. Once they are authenticated their app would make calls against your servers and you would in turn make calls against the Spark Cloud using existing access tokens. All cores/photons you would ship out would be pre-registered to your own account, not the user’s Spark Account

Thanks. Yeah, that’s the implementation I’m going with for now. I hope there’s no limit on the number of cores I can claim…

I have a question into Spark directly about this too. Sounds like better support for this in the future is on their radar.

1 Like

Yes, the current setup is obviously not ideal. It adds a level of complexity that’s probably not always needed (your own servers)

Does anyone know how the Nest thermostat network and cloud works?
I want my Photon to mimic the Nest way.

So please explain their network.


+1 for simplified claiming of cores for commercial products a la Nest for spark owners.

What Nest does as far as I know, is to call an API endpoint to register with the server and get a “claim code” to allow the app to claim it easily at a later step (instead of writing serial numbers or long codes)… So I am guessing the Nest product pings the server end point and registers with it with a long known serial number or UUID and in turn gets a “claim code” which is a 4 or 5 digit code if I remember correctly.

The app then logs in to the user account and asks the server to associate the device with the user using the short “claim code”.

And that’s that.

It’s similar to what spark does, but spark adds another layer of complexity because it then has to cope with multiple users that in turn have multiple users that each have a multiple devices registered to their account. let’s say Spark has to manage multiple “nest” companies.

Spark needs to release an official way of how to handle this officially as a temporary or interim solution or when it plans to release the final best practice for commercial products.

Right now, what I do (I am not running commercial product but prototypes), is I hard code the username/password to the app, and pre-claim the spark device to my account. Then my app logs in to spark overtime the session-token expires. I heard somewhere (can’t remember where) that you can set the expiration time for the token to not expire, but I don’t know if this is a good idea… Maybe it is.

Anyway. I also crave the right way to do this, so not to spend time coding a solution that will work around the recommended best practice or something that will not work in the future.

@friobo, Does your app have a concept of “users”? Like, do people log into your app? How do you know which of your devices they are allowed to use?

Yes it does. However I do have some servers in the middle… My servers talk to the spark cloud. So my servers have full access to all the spark devices logged in to the cloud. And my server is the one that picks what commands go to which device.

So again. Not ideal… I don’t know what’s the best approach.

Ok. So I don’t see why you are hard coding anything into your consumer-facing app. It sounds like all the spark api stuff is happening on your own servers? That’s how it should be happening in the current spark setup