Some findings about access tokens

After learning something about device-IDs and tokens I made some observations on my own
At first I collected all tokens with curl, later on from inside my app with an ‘NSUrlRequest’.
I found out, that I have more than one token assigned to my account, each of them capable of accessing all my cores.
This has been mentioned before.

The still growing list of my tokens (after some little modifications):

{
    client = spark;
    "expires_at" = "2015-02-17T15:04:53.226Z";
    token = a9fxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX716;
},
    {
    client = "spark-ide";
    "expires_at" = "2015-02-17T19:09:16.143Z";
    token = 493xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX2f5;
},
    {
    client = user;
    "expires_at" = "2015-04-22T12:35:14.552Z";
    token = dc2xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX341;
},
    {
    client = "spark-cli";
    "expires_at" = "2015-04-27T15:18:49.513Z";
    token = 7bfxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXb8a;
},
    {
    client = "ifttt-5545";
    "expires_at" = "2015-05-06T16:38:11.696Z";
    token = 8c3xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX6f5;
},
    {
    client = spark;
    "expires_at" = "2015-05-07T06:23:35.789Z";
    token = e08xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX65b;
},
    {
    client = spark;
    "expires_at" = "2015-05-07T06:26:57.338Z";
    token = bd8xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX0cf;
},
    {
    client = spark;
    "expires_at" = "2015-05-07T06:27:48.242Z";
    token = 345xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXfcc;
},
    {
    client = spark;
    "expires_at" = "2015-05-07T06:29:08.323Z";
    token = a23xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX08d;
},
    {
    client = spark;
    "expires_at" = "2015-05-07T07:31:12.942Z";
    token = 297xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXad3;
},
    {
    client = "__PASSWORD_ONLY__";
    "expires_at" = "2015-05-08T00:00:09.403Z";
    token = 8a1xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXe45;
},
    {
    client = "spark_devil";
    "expires_at" = "2015-05-10T10:47:46.529Z";
    token = 40bxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX19c;
}

The code to request my tokens is:

NSMutableURLRequest* request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://api.spark.io/v1/access_tokens"]];
NSString *authStr = @"joe@example.com:SuperSecret";            // like the example
NSData *authData = [authStr dataUsingEncoding:NSUTF8StringEncoding];
NSString *authValue = [NSString stringWithFormat: @"Basic %@",[authData base64EncodedStringWithOptions:0]];
[request setValue:authValue forHTTPHeaderField:@"Authorization"];

(This code is kind of a shortcut, more at sof)
However, it works.
What I found out is, that the spark-app on iOS does not run this kind of code at all. On launch either a new token is created, which then is stored inside the keychain, or a previously stored token is used. The app uses only one token. If that token is gone, because maybe only locally stored, another launch on a different device generates a new core. The old access token remains valid.
As said before, all my dozen tokens are working, and I still can create more. In fact I can create as much as I like, and delete them at will.
It appears to me, that all sayings that there is a reset are wrong. A new token is created as replacement for a non-void token. This behavior should be documented.

While looking at my tokens I noticed different clients. This refers to the username used to create the token.
Generating a new token introduces some extravagance:

curl https://api.spark.io/oauth/token -u spark_angle:spark
-d grant_type=password -d username=joe@example.com -d password=SuperSecret

with the username “spark_angle” generates a token showing “spark_angle” as client:

{
    "token": "446xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX52d",
    "expires_at": "2015-05-10T18:10:49.673Z",
    "client": "spark_angle"
}

I have read this,this and that. From what I can see is that the expiration of a token is not really an issue, automated replacement is. The iOS-app does it, so do others. But this is neither documented, nor is keeping already replaced tokens alive a clean solution.

Just findings. Besides the undocumented reset vs. replacement issue there is nothing to complaint about.

1 Like