Unable to use license/subscription REST API

I was unable to reproduce the failure, though there certainly couild be a detail I am missing. Here is the exact string I used. Will you double check for typos?  It can’t be the clientId, because that check is done first:

https://lucid.app/oauth2/authorize?client_id=Bijm...&redirect_uri=https://lucid.app/oauth2/clients/Bijm…./redirect&scope=licenses:admin.readonly

Additionally, I will get the list of scopes updated and determine a way to ensure it doesn’t continue to happen as new scopes are added. It has become very out of sync. Thanks for pointing that out.

Updating the doc would help 

Thanks for your response.

We're attempting to authorise at the account level using the account token authorisation endpoint:

https://lucid.app/oauth2/authorizeAccount

However, this results in the "invalid scope" error shown above.

In contrast, when we use the user token authorisation endpoint:

https://lucid.app/oauth2/authorize

the authorisation succeeds without any issues.

Our goal is to obtain an account-level grant, so we'd appreciate any guidance on whether there are additional requirements, supported scopes, or configuration steps needed for the account token flow.

For reference:

• Authorization Endpoints: https://developer.lucid.co/reference/authorization-endpoints
• OAuth 2.0 Account Tokens: https://developer.lucid.co/reference/authentication-methods#oauth-20-account-tokens

That makes sense.  Unfortunately, that endpoint does not work with account tokens and instead relies on the user granting the token having the correct admin role.

Account tokens are a bad solution to a common problem. How do users build an integration/process that isn’t tied to the permissions of a specific user. When the dev-platform was initially being built, account tokens were the solution. However, over time we have determined that they have a fundamental flaw: attribution. When an account token takes an action, there is no corresponding `user` for whom the action can be attributed. Our products are very `user` based in every other way. Its easy for an admin to understand that you have users and roles and by removing a user’s roles you remove their access. But, account tokens are these things floating out there that behave different and are potentially extremely powerful, based on scope.

So, we have been moving away from account tokens and limiting endpoints to user tokens. Some endpoints have an additional header, (Lucid-Request-As), which requires the caller to explicitly state their intention to act as an admin.

However, this only makes the original problem more severe. We are working implementing support for Service Accounts to be the long term solution to this problem. An account could designate a Service Account as the user, decoupled from any licensed user’s permissions. Unfortunately, I don’t have an exact ETA for when that will be available.

​@Michael B Thank you for the detailed explanation and the background on the decision to move away from account-level tokens.

That said, this puts us in a difficult position. We have already invested significant effort in building our integration around account-level OAuth grants to retrieve account-related information through your APIs. If the recommendation is now to migrate to user-level permissions, we would need to redesign parts of our implementation. However, from your explanation, it appears that this approach may become obsolete again once Service Accounts are introduced, resulting in additional rework on our side.

One of the biggest challenges we have faced is the lack of clear and up-to-date documentation. We have found information across multiple Lucid documents that is either inconsistent or outdated, making it difficult to understand which authentication model is supported for specific endpoints. In particular, if account-level scopes are no longer supported or are being deprecated for certain APIs, it is unclear why they continue to be documented as available options.

As an enterprise customer, we are trying to build a stable and supported integration, but the current limitations and changing recommendations make that extremely challenging.

​@Michael B We needed a clarification on subscription API, posted here: 

If you can help us with this query, would be appriciated