OAuth : Change of client's rights

Application Development
1

In order to get an Auth client, one should use the CLI to get the authorization from the administrators. Example (taken here):


$ ttn-lw-cli clients create \
    --client-id mybrand-gateway-manager \
    --name "MyBrand Gateway Manager" \
    --description "Manage your MyBrand gateway from the mobile app" \
    --organization-id mybrand \ # or --user-id htdvisser \
    --redirect-uris https://app.mybrand.com/oauth/callback/ttn \
    --grants GRANT_AUTHORIZATION_CODE \
    --rights RIGHT_GATEWAY_ALL,RIGHT_ORGANIZATION_GATEWAYS_CREATE,RIGHT_ORGANIZATION_GATEWAYS_LIST,RIGHT_ORGANIZATION_INFO,RIGHT_USER_GATEWAYS_CREATE,RIGHT_USER_GATEWAYS_LIST,RIGHT_USER_INFO,RIGHT_USER_ORGANIZATIONS_LIST

Once this request done and approved, will it be possible to update the rights given to this client? There is a long list of “possible rights” so I may not set them good at the first try.

By the way, how long does it take to get the request accepted?

Thank you

2

Yes, it will be possible to update the rights of your OAuth client later, but the users of your OAuth client will then need to accept those extra rights by re-authorizing your OAuth client the next time they use it.

The scope and duration of the review process depends on the network where you register your OAuth client. If you register it in your own tenant on The Things Stack Cloud, then the administrator (probably you) can approve it right away. If you register an OAuth client on The Things Stack Community Edition, the administrators will take some more time to review if and how the OAuth client benefits the community. Now that the first requests are coming in, we have started working on defining the review guidelines. Some things that the admins look at are:

  • The ID and name of the user / organization that owns the OAuth client should clearly identify who is providing the service. For public clients, this should typically be an organization with the brand name as ID. For private/testing clients this can also be a user ID. For personal testing clients, approval should not be needed (see issue). IDs or names that could be confused with official TTN IDs/names will be rejected.
    • The example uses “mybrand”.
  • The ID of the OAuth client should ideally consist of the brand name of the application, and the purpose of the OAuth client.
    • The example uses “mybrand-gateway-manager”.
  • The name and description should be clear. The name is typically the capitalized form of the ID. The description should explain to users what the application does.
    • The example uses “MyBrand Gateway Manager” as name and “Manage your MyBrand gateway from the mobile app” as description.
  • The redirect URI should work.
  • The rights should be appropriate given the name and description of the OAuth client.
  • The password grant should never be used. No exceptions.
  • The refresh_token grant should only be used when non-interactive access is clearly required.
3

Thanks. In my case, this is a request for The Things Stack Community Edition.

I have reviewed all the points that you have listed and I have filled a new request (cliend id: isca-lab-lora-provisioning).