ID-porten and Maskinporten can issue tokens to scopes controlled by Difi, as well as scopes controlled by other organizations.
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. An empty value means that clients of any integration type can get access_tokens containing the scope.
The available scope limitations are :
|maskinporten||Only for server to server integration|
|api_klient||For integrations consuming APIs that require an authenticated user|
In addition, there are some reserved integration_types like ‘idporten’, ‘krr’ or ‘eformidling’ for dedicated use cases as can be seen from the tables below.
You will not be able to register a scope to your client if there is a conflict with the client’s integration type and the scope. E.g. you can’t add a “maskinporten” scope to a “idporten” client.
The following scopes triggers special behaviour in ID-porten OIDC provider. They can be used by all customers.
|openid||Triggers an OpenID Connect-compliant authentication||idporten, api_klient|
|profile||Gives access to the /userinfo endpoint||idporten, api_klient|
|no_pid||Triggers a pseudonymous authentication||idporten, api_klient|
|eidas||Include the eIDAS attributes in the id_token. See eidas login||idporten, api_klient|
Any customer can self-service their clients with the following scopes:
|global/*||Scopes for global access to the Contact Registry||krr|
|user/*||Scopes giving Contact Registry details for the authenticated user||api_klient|
You need to ask us for permission to be able to use these scopes:
|idporten:dcr*||Scopes allowing for self-service of ID-porten integrations||maskinporten|
|idporten:scopes*||Scopes allowing for self-service of ID-porten/Maskinporten API management||maskinporten|
|idporten:authorizations.*||API for authorizations||api_klient|
|idporten:user.log.read||API for authentication history||api_klient|
|global/idporten.authlevel.read||API for authentication level of assurance||maskinporten|
ID-porten and Maskinporten protect a number of APIs from other organizations. See the links below for the complete list:
|URL to list of scopes||Description|
|https://integrasjon.difi.no/scopes/all||A list of scopes protected by ID-porten in Production|
|https://integrasjon-ver2.difi.no/scopes/all||A list of scopes protected by ID-porten in VER2 environment.|
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 can be set on a scope in order to activate it for external delegation in e.g. Altinn.
Such scopes will always follow this syntax:
scope ::= prefix ':' subscope
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.
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:
folkeregisteretor organization number)
For access to these scopes, you need to contact the organization owning the scope.