Skip to main content
When you create a Platform App, you select an app type based on how your app runs. Regardless of the method used, underlying principles still apply. If a user does not have access to content on the front end of the main Box web app, they will not be able to access the content using the API, unless they are impersonating another user. Some API endpoints require admin level privileges — like events.
App typeAuth methods available
User AuthenticationOAuth 2.0
Server AuthenticationClient Credentials Grant, JWT

​
OAuth 2.0

OAuth 2.0 is a client-side authentication method, widely used for its simplicity in authorizing users to Box API. It’s an open standard that allows users to grant applications access to their data in other applications. Similar to how logging in to a website with Twitter, Facebook, or Google works, Box’s client-side authentication involves redirecting a user from an app to the Box web app, where they log in and grant the app access to their data. For example, we use this auth type for users logging into our community forum. Select User when you create your app.
When to use OAuth 2.0?Client-side authentication is the ideal authentication method for apps that:
  • Work with users who have existing Box accounts.
  • Use Box for identity management, so users know they are using Box.
  • Store data within each user account vs within an application’s Service Account.
You can find a great Python OAuth 2.0 tutorial on GitHub.

​
Client Credentials Grant (CCG)

Client Credentials Grant verifies an application’s identity using a client ID and secret. This method is particularly useful for scenarios requiring server-to-server interactions without user involvement. Depending on the application’s configuration, it can authenticate as either the application’s Service Account or as a Managed User. Upon approval by an administrator, a CCG application will get assigned a service account to make API calls as by default. Select Server when you create your app. Client Credentials Grant is the default method, so a new Server Authentication app uses it unless you choose otherwise. Depending on your enterprise’s Switch server app auth type (CCG or JWT) setting, you can switch the method later or must pick it during app creation. See Choosing and changing the authentication method.
When to use CCG?Server-side authentication with CCG is the ideal authentication method for apps that:
  • Work with users without Box accounts
  • Use their own identity system
  • Do not want users to know they are using Box
  • Store data within the application’s Service Account and not a user’s account
  • Want to manage public and private key pairs
You can find a great Python CCG tutorial on Medium.

​
JSON Web Token (JWT)

JWT is an open standard that enables robust server-to-server authentication. This method does not involve end-user interaction. It allows an app, if granted appropriate privileges, to act on behalf of any user in an enterprise, thus facilitating powerful and seamless integrations. Upon approval by an administrator, a JWT application will get assigned a service account to make API calls as by default. Select Server when you create your app, then set the method to JWT. Depending on your enterprise’s Switch server app auth type (CCG or JWT) setting, you choose JWT during app creation or switch to it later from the Configuration tab. When switching is enabled, you can change between Client Credentials and JWT at any time.
When to use JWT?Server-side authentication with JWT is the ideal authentication method for apps that:
  • Work with users without Box accounts
  • Use their own identity system
  • Do not want users to know they are using Box
  • Store data within the application’s Service Account and not a user’s account
  • Do not want to manage public and private key pairs
You can find a great Node JWT tutorial on Medium.

​
User permissions and scopes

It is important to understand that even if an application has the right scopes to perform an action, the user associated with the Access Token making the call needs to have permission to perform the action as well and vice versa. For example, if your application is set up to read files, the authenticated user does need to have permission to read the file you are trying to access. To learn more about how scopes, token permissions, and user permissions work together, see our security guide.
Last modified on July 14, 2026