"UUID + token" vs "token-only"

[drasko]

Why is Meshblu using "UUID + token" approach, when sending only one token should be sufficient, as UUID can be encoded within the token itself?

[royvandewater]

The UUID is generally used to build relationships between devices through the permissions system, so we need to have a way to identify devices without granting permission to modify them.

As far as treating the UUID and Token as a single entity for authentication purposes, you can certainly do that. Meshblu supports both Basic Auth and Bearer Token Auth, which both allow you to post up a request using the uuid & token combined into one thing:

#!/bin/bash

UUID=6149d210-addc-41b0-b1df-fd90873a5eb8
TOKEN=f5e4c829731cae73f2edc0b3a9d3f74966768ce2

IDENTIFIER=$(echo -n "${UUID}:${TOKEN}" | base64)

curl -H "Authorization: Basic ${IDENTIFIER}" https://meshblu.octoblu.com/v2/whoami
curl -H "Authorization: Bearer ${IDENTIFIER}" https://meshblu.octoblu.com/v2/whoami

[drasko]

The UUID is generally used to build relationships between devices through the permissions system, so we need to have a way to identify devices without granting permission to modify them. @royvandewater I uderstand this perfectly, but Meshblu could generate UUID and security token that embeds this UUID.

For the routes where token is no needed you would pass only UUID (as usual).

For the routes where authentication is necessary, you would pass only security token, and Meshblu will derive UUID out of this token.

[iamruinous]

There are cases where you want to act on behalf of another device, yet use your authentication credentials to do so. By supporting explicit UUID in all cases it removes ambiguity and special cases.

[drasko]

@iamruinous I do not see the case where you provide auth_uuid from one device and auth_token form another. They always belong to the same device.

I am saying that auth_uuid should be encoded in the auth_token.