Is there a way to list activation tokens by license ID?

[taxilian]

I'm working on a tool to link licenses to user accounts in an existing web system -- then I'd like the user to be able to see basic information including their activation token (which is what I have them enter into the software to use it) and maybe some other info about the number of activated machines, etc.

I can see how to list all tokens, but is there a way that I'm missing that you can specify other arbitrary fields to query on such that I could say "give me only activation tokens assigned to license id {license_id}"?

[ezekg]

Yes, you can filter the tokens by bearer. For example, see the following:

GET /v1/accounts/<account_id>/tokens?bearer[type]=license&bearer[id]=<license_id>

You can also access a license's tokens relationship directly:

GET /v1/accounts/<account_id>/licenses/<license_id>/tokens

[taxilian]

Ahh, that makes sense now. To be honest the term "Bearer" is not one I would ever have interpreted with that meaning without help -- perhaps adding some examples would be a good idea?

And of course now I realize that I forgot a key piece of information here -- listing the tokens isn't actually useful to me because what I really wanted was to show the key itself, not the resource... which of course with a token you only get when you first make it or if you regenerate.

I knew that, I promise :-P this is the problem with doing most of the implementation and then having things come up and only getting back to finishing up 8 months later...

[ezekg]

You can think of a token "bearer" as the "owner" of a token.

But for most use-cases, I'd actually recommend not using tokens at all. You can authenticate with our API using a license key instead of a token, e.g. Authorization: License <key>. This will allow a couple things:

1. Allow you to display the license key within the licensing portal, which is essentially their API key.
2. Allow you to manage devices client-side from the portal, using the license key.

For most use-cases, license authentication is a better and much simpler choice.

[taxilian]

Inside the application that's absolutely what I'll be doing, but the app in question is an offline version of an online website app. I'm going to be selling the app from the website, so the plan is to optionally link the license to their user; in that case I want them to be able to sign in and see the information on the website. I could certainly store their license there, but I'd rather just store the license id and query the information as needed, since it's already on the server anyway

[ezekg]

I was referring to not using activation tokens at all. You can still utilize user tokens if you want to have a login like that. But instead of listing a license's activation tokens, I was saying that the simplest thing to do here would be to show and use the license key instead of the tokens (seeing as you can't see the token value anyways since it's not stored by us).

[taxilian]

Well, I could do that but I need something to give to users which is short enough to copy/paste -- that's why I'm using the activation tokens is because that's what the app requests from the user to activate it. In some cases I'll be selling these on paper and the license key (particularly if using an encrypted one, which I prefer to do) is not "user friendly".

I have them put in the "activation code" that I give them, then I format it as activ-${token} and use it as the bearer token.

[ezekg]

Have you thought of using plain text license keys, alongside license files for offline usage? This will give you shorter license keys but still allow offline use (with even more license information being available within the license file).

That's our recommended approach.

[taxilian]

I am using license files for offline usage, but I like being able to cryptographically verify the license key as well. I'll think on it a bit.

[ezekg]

We typically don't see those used together, but there's nothing particularly wrong with that either. Though we actually built license files to eventually replace signed license keys. The signed (and optionally encrypted) license file already contains the license's key attribute, so an additional signature on the license key is largely superfluous.

[taxilian]

yeah, this is one of those cases where I built things starting in one place and moving from thing to thing in a progression, and everything made sense... but I need to rethink if what I ended up with still makes sense, as well as how difficult it would be to rework it =]

Always good to rethink your assumptions, just not always easy.