Scope

ID-porten and Maskinporten can issue access tokens to scopes controlled by Difi, as well as scopes controlled by other organizations.

Scope model

The following attributes are available for a scope:

Example:

{
    "name": "altinn:serviceowner",
    "prefix": "altinn",
    "subscope": "serviceowner",
    "description": "Full access scope for the Altinn Service Owner API. Used for clients not specifying any API limitations.",
    "visibility": "PUBLIC",
    "token_type": "SELF_CONTAINED",
    "at_max_age": 1000,
    "requires_user_consent": false,
    "requires_user_authentication": false,
    "requires_pseudonymous_tokens": false,
    "accessible_for_all": false,
    "delegation_source": "https://tt02.altinn.no/",
    "allowed_integration_types": [
        "maskinporten"
    ]
    "last_updated": "2020-11-03T11:28:13.826+01:00",
    "created": "2020-11-03T11:28:13.826+01:00",
    "owner_orgno": "991825827",
    "active": true,

}

Scope limitations

Some scopes only work towards Maskinporten, others only towards ID-porten, while some can be used for both. This depends on the allowed_integration_types attribute registrered on the scope:

You will not be able to register a client with a certain scope if there is a conflict with the integration_type of the client and the allowable_integration_type of the scope. E.g. you can’t add a “maskinporten” scope to a “api_klient” client.

See also client registration.

List of Reserved scopes

The following scopes triggers special behaviour in ID-porten OIDC provider. They can be used by all customers.

List of scopes for APIs from Digitaliseringsdirektoratet

Any customer can self-service their clients with the following scopes:

For the following scopes, you need to ask us to add them to your client manually:

List of scopes for APIs from 3rd parties

ID-porten and Maskinporten protect a number of APIs from other organizations. See the links below for the complete list:

See the allowed_integration_type claim on each entry to see if any scope limitation applies.

You need to ask the organization owning the scope to grant you permission to use these scopes, unless the flag accessible_for_all is set.

Delegation source

The attribute delegation_source can be set on a scope in order to activate it for external delegation in e.g. Altinn.

Scopes syntax for scopes controlled by third parties

Such scopes will always follow this syntax:

scope ::= prefix ':' subscope

The prefix is a string which is manually linked to a specific organization. It may be the organization name, or other suitable value. An organization may have multiple prefixes.

The subscope is created by the owning organization itself using selfservice. ID-porten place no specific rules on how subscopes should be named or structured, as different organizations have vastly different needs to structure their APIs. Nevertheless, some recommendations apply:

• the prefix should natually identify the owning organization or its subsidiary / application (example nav or folkeregisteret or organization number)
  • if multiple organizations share the same scope, the prefix should identify the sector (forsikring)
• subscope should primarily identify the resource and not the API (trygdeopplysninger or adresse)
• subscope should contain various postfixes to differentiate between read and write access to the resource (nav:trygdeopplysninger.write)
  • absence of a postfix should normally only imply read access

For access to these scopes, you need to contact the organization owning the scope.