What is an OAuth scope?
Short answer
OAuth scopes are the values that state which information or permissions the application wants to access on the user's behalf; they are sent in the authorization request separated by spaces, e.g., openid email profile (RFC 6749 §3.3). The provider has the user approve these permissions, and the token it issues is valid only for the approved scopes. In OpenID Connect, the openid scope is mandatory to request an ID token; scopes such as email and profile bring the related claims. In TR7 AGS, in the OAuth2 and OpenID Connect types, the scopes are entered in the OAuth Scopes field. For built-in providers, if the field is left empty, the default scopes in the catalog are used, and if it is filled in, the entered value applies; in e-Devlet, the scopes are separated with ;. In Custom Provider, if Fetch Endpoints from Issuer is used, the openid, profile and email scopes announced by the provider are written to the field.
Where It Is Used in TR7
| Where | Field / label | What for |
|---|---|---|
| AGS → Authentication → Authentication Providers (OAuth2, OpenID Connect) | OAuth Scopes | The information and permissions requested from the provider |
| Same form | OAuth Provider (built-in provider) | The default scopes used while the field is empty come from the catalog |
| Same form (Custom Provider) | Fetch Endpoints from Issuer | Writing the identity scopes announced by the provider to the field |
| Same form (Custom Provider) | User Info Parameters; {scope} placeholder | Adding the scope value to the user info request as a parameter |
Default Scopes in Built-in Providers
| OAuth provider | Default scope |
|---|---|
| Google, Microsoft, GitLab, Keycloak, Okta, Auth0, LinkedIn | openid with profile and email |
| GitHub, GitHub Enterprise | read:user user:email |
| Apple; only in the OpenID Connect type | name email |
| X (Twitter) | users.read tweet.read offline.access |
public_profile email | |
| Yandex | login:email login:info login:avatar |
| e-Devlet | Kimlik-Dogrula (scopes are separated with ;) |
Common Misconceptions
- "Requesting more scopes is harmless." Unnecessary scopes make the user consent screen heavier and increase the impact of a stolen token; only the information that is needed is requested.
- "Group information comes automatically from every provider." At most providers, information such as group and role requires a separate scope or additional configuration on the provider side; the incoming claims are mapped to AGS fields with Custom User Attribute Mapping.
- "An OAuth scope is the scope of the access rule in AGS." OAuth scopes are the permissions requested from the provider; which application the user accesses is determined by the Decision Point, Allow and Deny steps in the AGS flow.
How it is done in the documentation
