Activate machine using license key as bearer token

[nCubed]

When activating a machine, the docs state the license key can be used as the bearer token:
https://keygen.sh/docs/api/machines/#machines-create

An authentication token with privileges to create the resource: either an admin, the product it belongs to, the license it belongs to (via license key or an activation token), or the user it belongs to (unless the license is protected)

When using the key, an error is returned:

"errors": [
    {
        "title": "Unauthorized",
        "detail": "You must be authenticated to complete the request",
        "code": "TOKEN_INVALID",
        "links": {
            "about": "https://keygen.sh/docs/api/authentication/#token-authentication"
        }
    }
]

When using the admin token, Bearer {token} machine activation works like a charm.

Attempting to use the license key fails. I've tried both Bearer {key} and License {key}.

FWIW: The policy attached to the license is both strict and protected.

Related Question

When activating the machine, I noticed you must provide the license Id in the attributes (relationships); is there an option to use the license key instead of the id?

Any guidance would be appreciated.

[ezekg]

The Bearer {token} authorization scheme only supports API tokens. Likewise, the License {key} only supports license keys. To authenticate with a license key, you will need to first set the license policy's authenticationStrategy to LICENSE or MIXED, and then use the License {key} authorization scheme. If the License scheme was failing, it is likely due to the policy not allowing license key authentication, or the license key was incorrect, expired, or suspended. For more in-depth docs on API authentication, check out the docs (there is sections on License Key Authentication as well as Token Authentication).

And to answer your related question — we do not support passing in a license key instead of a license ID in relationships. You will need to first validate the license, which will do 2 things: first, it will let you know if an activation is even needed (i.e. a VALID license doesn't need to be activated, granted the validation was scoped with a fingerprint), and second, it will provide you with the license's ID in the validation response body, under data.

Hope that helps? Let me know!

[nCubed]

Thanks for the in-depth and quick reply Zeke.

When I posted this question, the authenticationStrategy was set to MIXED. The license key was valid (not expired, etc...). So, I'm not quite sure why it was failing. And since then, I've re-written most everything and have dumped the prior policies/licenses. (fwiw, we're just now getting started w/ Keygen and everything is in a dev environment, running with integration tests.)

Could you expand a bit on this statement?

likely due to the policy not allowing license key authentication

Are you referring to the authenticationStrategy? Or is there another policy setting that disallows license key auth?

Regarding the 2nd question, makes sense and I've validated that workflow. Thanks!

[ezekg]

Yes, I was referring to the authenticationStrategy. If you're still having trouble, feel free to send me your account ID (or a request ID, should be meta.id in the error response) and I'll take a look at your request logs to help determine where the issue is. One thing to double check is that you're sending the key exactly as it is for the license object's key attribute.

Feel free to shoot an email to [email protected] if you want to provide code that I can look at.

[nCubed]

Not sure what was occurring yesterday, but after the re-write everything executes as expected. The only major difference is I was originally using an unencrypted key; now I'm using an encrypted key. Regardless, everything appears to be working as expected. Thanks!

[ezekg]

Great to hear! When using an encrypted key, you'll need to ensure that you're using the entire key, not just part of it. It should look something like the key below. Another limitation is that the maximum byte length of a license key used in the Authorization header must be less than 8,192 bytes (8KB), the maximum acceptable length of an HTTP header.

key/emVrZUBrZXlnZW4uZXhhbXBsZQ==.D1pk7hqD_KNV9UNpl1IDQqpa4qaBjFBNrtP74yEM7v0xCmLRrDhZdSHGx47TN2RKARfGIigX9tE4yVOjhQvfAQ==

If your keys are larger than 8KB, you'll need to use a license token instead.