client_id
and client_secret
, comparable to username and password. The client credentials are used to fetch an access token, which in turn is used for authentication when accessing Naviga Content tools and APIs. Both client credentials and access tokens are part of the OAuth2 specification. imid:admin
is required. Auth can be either an ID-Token or Access-Token, either as cookie or in the Authorization HTTP header as Bearer token.groups
, and the recommended way of using scopes
.scopes
["permission"|"role"]:[unitName|"*"]:[serviceName]:[entityName]
permission:gl-news:opencontent:view
permission:*:opencontent:view
role:gl-news:opencontent:readOnly
role:*:opencontent:readOnly
/v1/organizationApplications.create
in the Admin API. The scopes that define roles and permissions that the applicatin can assume should be entered in the allowedScopes
payload parameter. See the documentation for a full description.client_id
) as well as one initialclient_secret
that you'll need to fetch an access-token. To enable easy rotation of secrets, Naviga ID supports multiple client_secret per application. For more details, see the section about rotation of credentials lower down on this page.groups
/v1/organizationApplications.create
in the Admin API. See the documentation for a full description.client_id
) as well as one initialclient_secret
that you'll need to fetch an access-token. Naviga ID supports multiple client_secret per application, to enable easy rotation of secrets. For more details, see the section about rotation of credentials lower down on this page..client_secret
, Naviga ID Organizational Applications support multiple credentials. That way, it's possible to rotate credential with zero downtime in services by creating a new credential for the application and updating all places where the old credential is used before removing it from Naviga ID.