Token expiration

Today I found out that access token of my spark core expired, and I even have no idea when. There were no warnings, no emails, nothing - it just stopped working.

Is there some way to make a token that never expires? How can I relay to anything built on Spark Core if it stops working at random moments of time?

If you use the search function of this forum, you’ll find that this has been previously discussed, on multiple occasions.
There are some options under consideration, and it’s definitely something that’s being looked at.
As far as I’m aware, the token has a duration of 90 days, after which it is reset. If you note that, you can at least prepare for next time, until another alternative is implemented.

1 Like

Thanks @Moors7, but my point was that this bug (it’s definitely a bug) has been there since the beginning, and nothing is changing despite of three (this is the forth) posts about it.

Hi @vkhq

I don’t think this is a bug–this is the way OAUTH at Twitter and other sites works under the hood. This is considered good security practice. If you have ever had to re-login to a site like Twitter or ebay after going idle for some time, you are seeing this type of policy in action.

I think a good strategy that would always work no matter what the policy decision on expiration of tokens would be to detect the expired token in the web code and prompt the user for their credentials to get a new token on expiry.

That would take the surprise out of the picture and your web side code would just ask the user for credentials. If you have a situation where your code just needs to do that without user intervention, then it needs to store the credentials.


While I certainly understand the security implications, it does make it hard to use a Spark in a long-lived project where you’d like to be able to deploy and forget about it.

Ideally, I’d like to see some convenience functions that would let code running on a Spark:

  1. Read its current token and know when that token will expire
  2. Request a new token and update it internally
  3. Acknowledge to the cloud that the new token is in place (probably sending both old and new token)

On the cloud side, I’d suggest that when an old token expires, its value should be retained for the sole purpose of allowing requests to do the above-mentioned token reset.


Thanks for you reply @bko, but in my case (and in many other, I guess) there are no alive users. There’s a crontab script that is collecting GPIO data from Spark.core, it works 24/7 without any human interaction. Time-to-time (may be once per month) someone may check the status, that’s it.

As @dougal mentioned, I want to build up the system, deploy it, and forget about it.

In addition, I don’t quite understand, how expired tokens help to improve security. Banks, Paypal, Amazon passwords, ssh keys never expire, do we have any problem with it? If we do, why don’t account password expire?

I don’t really want to argue the security implications here. Spark can have expiring tokens or non expiring tokens for all I care. I think of this as a convenience for some folks. An access token is meant to represent a leased key to some privilege and for convenience you’d like the lease to go for infinity.

You are wrong about SSL/TLS keys never expiring at banks, Paypal, Amazon, etc. and heartbleed was a perfect example of why renewable security can be important.

Here is my concrete advice to you: Change your cron job to (1) check for token expiry via the current API since the request returns a particular error and (2) embed your username and password in the cron script to request a new token when ever you find one expired. This has the exact same security as a never expiring token.


@bko How can I be wrong about it? Their passwords never expire, it’s a fact.

And your solution is not “exact the same security”, it is weaker, because I have to store my spark account password in plain text on the server side. I don’t actually care about GPIO data that hackers (or zog) can read from the core, but I would like to keep full access to my account.

Hi @bko, is that meant the Tinker apps is using Username and password to access the Core ? (Sorry I had not review the code in Mobile Apps yet). Currently I still using the HTML for my tests and using Token to access.

The Tinker app has to use an access token to talk to the cloud API just like everything else. I have never looked at the source, but I believe it gets an access token automatically using your username and password.

In addition to reading variables and events and calling Spark functions, the access token also allows you to reprogram a core with new firmware, so having an access token allows you do everything but get new or delete access tokens.

Is there any updates? The bug is still there, tokens expire within three months. BTW, how spark team came to “three months”? Why not “a week” or “a year”?

Fix it please, it’s very annoying.

I hate to say it, but it’s not ‘a bug’. Let me put it in perspective; you wanting a car to have only three wheels, does not make all four wheel cars ‘buggy’. It’s a design choice made by the producers. The fact that you do not agree with it does not make it faulty.
Having said that, I can fully understand why you’d like to have a longer lasting solution. I’ve ran into the issue as well whereby I was frantically looking for mistakes in my code, when it turned out to be an expired accesstoken. Luckily that only happend once, since I now know to expect it resetting after 3 months, so I can act accordingly. I’m not sure if you’ve tried the alternatives offered, but they’re definitely worthwhile checking out.

That (un)fortunately isn’t true either. The accesstoken allows you to to the exact same things as you can do with your mail/pass credentials, save for creating/deleting accesstokens. Just take a look at the JavaScript library for example. That means you’ll have the same amount of safety whether you use your accesstoken, or your regular credentials. The beauty of the accesstoken lies in the fact that you can make it expire after a while, whilst still maintaining ownership of your account through your regular credentials.
I’d suggest letting your CRON script log in through your mail/pass and aquire the accesstoken that way, until a more convienient solution has been made available. A customisable expiration date is most certainly on the backlog, but I guess the Photon currently has priority (for which I can’t blame them ;)).

1 Like

To be fair, there are a few other things you can do with a username/password that you can’t with an access token. Like potentially access code and other projects on the webIDE, change the password making all auto-access-token-generating scripts require updating anyway, etc.

If the solution to a long-term deployment is “use the username and password” why have access tokens at all? It makes access tokens sound like a solution waiting for a problem to me. Since I can “expire” my username/password any time by changing the password, that “benefit” is null… unless someone got my username/pass from a text file/script and changed it for me (through something like the ShellShock exploit maybe?)

This is quite a big deal for non-tinkerers. What is Spark’s (@zach) official solution to someone who want to put core’s in their products/projects that have no humans to enter credentials on a regular basis and don’t want to have a separate username/password for every installation? (since you wouldn’t necessarily want people who have access to one project/installation to have access to all others.)

An ideal access token system would let the user decide how long they want their token to live. Much the way many forms of secure certs work. You can pick the expire date either by specifying it during creation or purchasing many years in advance. Its not something that is fixed at only a single period of time because the creators and users/backers of the system know everyone’s situation isn’t the same.

I would:
Accept the limits of a local cloud (not being completely feature parity with spark cloud) and change the code there dealing with tokens to suit the needs of the project. From the sound of it though, the features you need are all in the local cloud code already.


Create new username/passes for each project and transfer (unclaim/claim) the relevant cores. Then implement the token lookup suggestions in a monthly cron. That way there is some protection between accounts/projects in case of a breach on your system that creates new tokens.

I do not want to visit a dealership to “renew” my car keys - what’s wrong with it? I don’t want to realize that my car doesn’t start anymore until the keys are renewed, when I’m 300 km from home - what is wrong with it? Does your bank disable your online banking password that can be renewed in branch only? Do your web-hosting SSH keys expire? Could you recall any credential around that just silently expires without any notification?

There’re two alternatives: 1) add “renew keys” event to a calendar 2) store accout password on some server w/crontab-ed renewal script. Both are obviously terrible.

But those tokens also have expiration date. So I’ll need to use script with hardcoded user/password in it for renewing token needed for renewing token needed for controlling that damned core. We need to go deeper :slight_smile:

Indeed, because that does not solve the problem.

The official solution to this problem is an upcoming feature that we’re working on called the ‘Product Creator Workflow’. This will allow creators to define a ‘Product’ that has end users that are different from the product creator. In other words:

  • Joe creates a Spark-powered product called a Widget
  • Joe defines a Widget and redefines a bunch of Photons/P0s as Widgets
  • Jane buys a Widget from Amazon
  • Jane creates her own account when she downloads the Widget mobile app
  • Jane is in control of her own Widget

In discussion of token expiration we’re mixing a lot of metaphors here. Expiring access tokens is an extremely common mechanism for keeping accounts secure. Typically the way this works is that when a user puts in their username/password to an app login, the app requests an access token, which it uses to keep the user logged in for a certain length of time. At some point (30 days and 90 days are common), the access token expires, and the user is required to put in their username/password again. The logic for dealing with an expired access token is baked into the app. If you’ve ever seen a “keep me logged in” checkbox, you’re seeing this feature in action.

I think the point that @JackANSI and @vkhq are raising here is that this doesn’t line up with totally automated systems which are expected to interact with a device forever and never fail. I agree that this requires a different mechanism. As we build out the ‘Product Creator Workflow’ and establish administrative accounts, we will be sure to discuss how this behavior should change going forward. Thank you @JackANSI and @vkhq for the feedback.


1 Like

Why don’t we just get rid of expiration dates for that type of users?

I have just been bitten by this, too. I have to admit I didn’t realise that the spark core’s ability to be embedded in a project and just left to do its thing was hamstrung by this ‘feature’. Any progress on a workaround such as “keep logged in” or user/pass instead of token? :slight_smile:

@zach Any update on timing for the Product Creator Workflow?

We’ll be releasing a bunch of tools at the end of March that should include the solution to the issues here


It’s the end of March, are there any updates regarding this issue?