> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cognite.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Design principles and best practices

> Design principles and best practices for managing authentication and authorization in Cognite Data Fusion (CDF).

By connecting CDF to your identity provider (IdP), you can use the IdP framework to manage access to CDF data securely.

This article explains the [design principles](#design-principles-openid-connect-and-cdf) and [best practices](#best-practices-register-applications-and-set-up-groups) to manage access to CDF.

<a id="design-principles-openid-connect-and-cdf" />

## Design principles: OpenID Connect and CDF

This section outlines the design principles to manage access to CDF.

<a id="authentication-and-applications" />

### Authentication and applications

**Authentication** is about determining the identity of a person or application trying to access a resource. It establishes if they are who they say they are.

Applications and users need to get a **token** from the IdP to authenticate and get access to CDF. The token is a very targeted key that grants access to an identity (a **user identity** for people, a **service principal** for applications.)

<a id="authorization-and-groups" />

### Authorization and groups

**Authorization** is about determining what level of access an authenticated person or application has. It specifies what data they're allowed to access and what they can do with it.

Access to CDF data and capabilities in CDF projects are governed by policies defined in the customer's IdP and by resolving the policies into one or more CDF groups where the access scope is defined. The policies are specified in the claims in the tokens that the IdP issues.

You can configure CDF groups to use any OAUTH v2.0 claim to determine access. The most commonly used claim type is `groups`, which is also the claim type recommended by Cognite.

You need to create AD groups to govern access rights to CDF for applications (service principals). For each security group a service principal is a member of, a groups claim is created and entered into an access token for the service principal.

<Warning>
  **Group membership limits**

  In larger organizations, the number of groups a principal is a member of may exceed the limit of 200 groups that AAD will add to a token.

  To resolve the issue, you need to configure your CDF project to call the MS Graph groups endpoint to obtain group information for the principal:

  1. Sign in to CDF as an admin and navigate to **Admin** > **OpenID Connect**.

  2. In the **Token URL** field, enter `https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token`.

     Where `$TENANT_ID` is the ID of your Microsoft Entra ID tenant.

  3. Select **Save configuration**.
</Warning>

<a id="best-practices-register-applications-and-set-up-groups" />

## Best practices: Register applications and set up groups

This section outlines the best practices for registering and configuring applications to **authenticate** with CDF. You'll also find information about setting up groups to **authorize** what data users and applications can access and what they can do with the data.

<a id="register-and-configure-applications-for-authentication" />

### Register and configure applications for authentication

The general rules for applications are:

* **Service applications** (applications that have no human interaction, for example extractors) use the [client credentials](/cdf/access/concepts/authentication_flows_oidc#client-credentials-grant) authentication flow. Service applications are sometimes referred to as *daemon applications*. You need to register each service application separately to provide specific access for different service applications and distinguish between security contexts.

* **User applications** (applications that require human interaction, for example the CDF application, connectors, and web applications) use either the [authorization code grant](/cdf/access/concepts/authentication_flows_oidc#authorization-code-grant) flow or the [implicit grant](/cdf/access/concepts/authentication_flows_oidc#implicit-grant) flow, depending on the implementation choices of the client application. Where supported, you should use **PKCE**.

Visit [Register and configure applications and components](/cdf/access/entra/guides/configure_apps_oidc) to find the detailed configuration and registration steps for Cognite apps and components.

<Warning>
  When you register applications using the **client credentials** flow, you should **NOT** share client IDs and secrets across multiple applications, even if the applications have common authentication requirements in CDF. Sharing client IDs and secrets across multiple applications can cause issues with audit logs, with events from multiple entities being identified under a common client ID. The applications may also be subject to rate-limiting.
</Warning>