Why did my access token expire?

So I’ve been enjoying the extended run times of my Spark and have been letting it chug away taking some 1-wire temperature readings. I went to check my data and found that it had stopped collecting 4 days ago with the following information:

2014-03-14 23:36:01.384169, Response Code: 400:{
  "code": 400,
  "error": "invalid_grant",
  "error_description": "The access token provided has expired."

I did add another Spark to my account, but I think that was several days before this timeout. I found a thread talking about how a mobile app logging in would reset the Token (though I think that’s been addressed), but I haven’t used the mobile app.

Since my Token is imported from an external file, I can see the I changed it to access the new core several days before the token expire:

Mar 11 21:47 credentials.py

Checking the Web IDE it tells me that my Token has indeed expired and there’s a button to reset it, so easy-peasy to get that sorted out. But I’d like to have a better understanding of when my token might go AWOL so I don’t have big holes in my data.

Thanks for any thoughts or explanations!

Dave O

I think the conflicting issues of access token has been resolved on the api server.

So no worries on that.

There’s a time expiry for the access tokens and I dont think we have control over it for now

Right now the expiration date for access tokens is set at 90 days. You can see when your tokens expire by checking the access tokens endpoint http://docs.spark.io/#/api/authentication-list-all-your-tokens


1 Like

Spark arrived around December 14th, access token expired about March 14th - hang on, doing the math here (carry the one, plus, four, five, switch hands, six, seven, um) - yep, seems like about 90 days! I think I can confirm that the token expiration system is working! :slight_smile:

I am a little disappointed that I had to wait almost 12 minutes for a definitive response from Spark on this though, but I guess you guys have to sleep sometime! :blush:

Dave O


@dorth … they would have replied sooner, but their access_token has expired and they needed to get another sorted, forst. :stuck_out_tongue:

I guess you’ve figured it out by now, but you can automate the creation of new tokens. From http://docs.spark.io/#/api/spark-cloud-api-authentication

# Using curl in your terminal
curl https://api.spark.io/oauth/token -u spark:spark \
     -d grant_type=password -d username=joe@example.com -d password=SuperSecret

# A typical JSON response will look like this
    "access_token": "254406f79c1999af65a7df4388971354f85cfee9",
    "token_type": "bearer",
    "expires_in": 7776000

Obviously, it would not be the smartest idea to put such automation code in your end application. :wink: But a server cron job set up somewhere to do it for you once a month and email you about its success or failure should do the trick.

I’m still trying to find something the Spark team has not already thought of, even if not implemented yet. They’re proving to be a rather good crew. :smiley: Bet they could use some help with all the coding yet to be done, though. Toomany invites to exciting off-shore destinations to show of the 'core! :stuck_out_tongue: (And so they should!)


today my first toke expired, I went through the web ui to request a new token.

Is there anyway I would be able to request a token that will never expire?

1 Like

This has been discussed already, earlier in this thread. Simply scroll back up and have a read to learn more.

The short answer is, “No, not at this time. But there are plans in the making AND you can automate the process of creating new tokens, using authenticated Spark API requests.”


I wonder if there is any plan at all to create non expiring token in the future. I have a Spark core that I use from three different resources and all of them require the access token, changing the access token means connecting to all of the server and manually changing them.

Yes. I can automate it, but there are always limitations on platforms, say no cron jobs support, etc. Furthermore, why not have never expiring token so an app requires no maintenance at all? I think that’s why we have a delete token feature, if the token is ever compromised we just delete it and create a new one.


Hey @Iv4n,

I brought this up and eventually, there will be an API endpoint for you to generate new access token. The expiry for now is kind of generic with some security in mind.

It’s hard for a one size fit all solution but I believe you can change that if you run a local cloud in future or when the feature to control your access token is released!

I’ll keep this in mind and when the :spark: team starts working on the access token control feature, we will see if the user can be given control over the expiry.

Cheers! :slight_smile:

1 Like

You can generate new access tokens today but they will still expire:


I think you should think about the business of running a cloud service and you might see why they don’t want to provide non-expiring access tokens.

Eventually you will be able to run your own cloud and then the policy will be for you to decide.

I’ve thought about it and cannot see the business case as obviously as you can, Brian@bko, so this would be better spelt out. The technical case for the option of an unexpiring access tokens is a good one. And should a subscription not be paid (desperately trying to read the Spark Team’s mind as well as you seem to be able to) a perpetual access token can be revoked.

@psb777, Spark has absolutely no desire or plan to charge the DIY user for its cloud service. Period.


I think (and this is my opinion) that it is better in general to have expiring authorization tokens and a renewal mechanism. The experience with oAuth is illustrative here. Your login id and password are your actual credentials and the access_token is a time limited lease of those credentials. That is all I meant.

Totally, there is a security trade-off to be made there. We’ll be adding a lifespan type parameter when creating and managing access tokens, so you can create a very long one (20 years, etc) if you really want. We’ll also update the CLI to let you list / create / revoke tokens as well to make it easier to create and manage these.



I may be dense, but I don’t get it. If I create an app with a web or smartphone component, how do I update the code when a token expires?

Oh, I am dense! The token is reset not replaced with a different one, correct?
I will go back and read to see how to automate the reset so my app does not stop working…


if you use the default :spark: Mobile app and Web IDE or even Spark-Cli, i believe it is smart enough to ask for a new access token when it expires. :wink:

I’ve just been burned by this. It might perhaps be sensible for the part of the IDE that discloses API keys to VERY PROMINENTLY state an expiry date.

The security model that’s been advanced above is incorrect:

  • There is certainly sense in having access to an API happen via a revocable/expirable token, but only because it means that the password doesn’t have to be stored in plaintext by the client software.
  • Where the client software is making calls in service of interaction with a human user then expiry can be dealt with easily (the human is right there…)
  • Where the client software is operating autonomously (collecting events from an API and delivering them to a database in my case), expiry doesn’t make sense as dealing with it requires …storing the password in plaintext, thus defeating the purpose of the exercise. Revocation is the appropriate mechanism in this case, which means issuing non-expiring keys.

Agreed, in that I think at least the Settings page of the Web build system (where the token is displayed) should state the expiry date – or at least a notice to tell new users that their token will eventually expire.

Meanwhile, I have noticed that the CLI tools retrieve and display a valid access token as login time. This implies that any deployed app should be able to do the same thing, certainly if a human is available to re-authenticate the spark.io account periodically. Perhaps a separate account is warranted for certain projects, so as not to disclose one set of user/pass credentials for everything? (Messy, random idea only.)

1 Like

Hi @gruvin,

Definitely agree, I think that’s a great feature idea, the expiration date should be displayed prominently (ping @jgoggins). When you login to the CLI, the CLI is using your credentials to create an access token, so yes that’s absolutely possible for any other app to use, the relevant code is here: https://github.com/spark/spark-cli/blob/e9e2c9c815d190f7416337557878d2385de10bd3/js/lib/ApiClient.js#L129

I’ll add a task for adding the expiration date! We want to add better access_token controls in general, but that might need to wait for our round of hiring to be done :slight_smile:


1 Like