OAuth Scopes

Overview

OAuth scopes allow you to specify the level of access your application needs to a user’s account. When initiating an authorization request, users will be prompted to consent to the requested scopes. By restricting your application’s scopes, you provide transparency to the user and protect their account from misuse.

Scopes are also available for use in the Roles API to provide granular control over what users can do in Qlik Cloud.

Note: Scopes can only limit access for OAuth tokens; they cannot be used to grant any additional access to the user.

How it works

As an integration developer, you specify your desired scopes in the initial OAuth authorization request.

GET /oauth/authorize?scope=automations apps:read spaces:read identity.name:read

The requested scopes are presented to users for their approval. Any previously approved scopes are not presented again to the user but are still available for the application to use, but applications should always examine what scopes are available on tokens because users can remove previously approved scopes between authorizations.

The authorization server will attempt to grant all the scopes in the client’s allow list even when the scope param is empty, but only scopes in the allow list that are approved by the user will be granted. To request scopes for approval from the user, they must be explicitly included on the authorization request using the scope query param. The offline_access scope is an exception, it won’t be granted implicitly, and it must be requested to get a refresh token.

Available scopes

Note: The user_default and admin_classic scopes should be used only where needed. These scopes are dynamic and may change over time. Good practice is to enforce least privilege principles and assign the specific scopes required for the OAuth client.

Scope	Description
user_default	Full access to your account and content (dynamic - use only where necessary, always enforce least privilege principles as good practice)
admin_classic	Full administrator access to your tenant (dynamic - use only where necessary, always enforce least privilege principles as good practice)
admin.apps	Read and manage all apps in the tenant, with full access to all private content in the app
admin.apps:export	Export all apps in the tenant
admin.apps:read	Read all apps in the tenant
admin.automations	Read and manage all automations in the tenant
admin.automations:read	Read all automations in the tenant
admin.spaces	Read and manage all spaces in the tenant
admin.spaces:read	Read all spaces in the tenant
apps	Read and manage your apps
apps:export	Export your apps
apps:read	Read your apps
automations	Read and manage your automations
automations:read	Read your automations
automl-experiments	Read and manage your ML experiments
automl-deployments	Read and manage your ML deployments
identity.email:read	Read your email address
identity.name:read	Read your full name
identity.picture:read	Read your profile picture
identity.subject:read	Read your user subject identifier
spaces.data	Read and manage your data spaces
spaces.data:read	Read your data spaces
spaces.managed	Read and manage your managed spaces
spaces.managed:read	Read your managed spaces
spaces.shared	Read and manage your shared spaces
spaces.shared:read	Read your shared spaces
offline_access	Access resources while you are offline