As you may have seen from the selection of different authentication types, there are several types of users supported by Box. The types of users may have different types of access patterns, permissions within the enterprise, and the right authentication method to use when creating tokens. In this article, we'll cover the general hierarchy of standard Box user types — Admin, Co-Admin, Managed User, External Collaborator — as well as API-only users such as Automation Users and App Users.
Enterprise Box Users
This is the most common user type and has the broadest deployment in Box. They are your everyday individual users of our product — whether they be admins, security, sales, etc. — they all have their own Box account and log into it using an email and password.
We refer to these users based on their hierarchy and access inside of a Box enterprise:
This is the main account that owns the overall enterprise. There can only ever be a single main administrator of the enterprise. The Admin has full access to all of the enterprise and user settings as well as content. From their perspective, they are able to create new users, can promote other accounts to Co-Admin, and can access all content across all users if needed. From an API perspective, this is the token with the largest set of scopes for performing admin-level tasks, impersonating users, etc.
These are users that have been promoted by the Admin and are given specific permissions beyond what a normal user would receive. When making them a Co-Admin, the main Admin can choose what extra permissions they are granted, which the co-admins themselves cannot change. This may include things like managing users or access to all enterprise events. In many cases, these are individual users or group accounts (like IT or security) to help run the enterprise, but in some cases, enterprises choose to create a Co-Admin account specifically for partner applications with the relevant permissions. From an API perspective, these are often privileged tokens with extra access, but note that a Co-Admin is never able to impersonate or access the main Admin or other Co-Admins, even with full permissions given.
More on Co-Admin privileges can be found on our Co-Admin Permissions Guide.
These are the day-to-day users of Box that belong to the enterprise. The main admin or a co-admin has created accounts for them, and they are able to store content, collaborate on it, and work with other individuals or teams inside of Box. Their permissions will often be much more at the content level rather than enterprise level as defined by our collaborator matrix that can be found here on our Collaborator Permissions Guide.
From an API perspective, a token generated for that user will inherit the same access they would see when logging into the Box web application, and nothing more, but these users can be accessed by Admins or Co-Admins with sufficient permissions to perform any required actions from an API perspective as long as they belong to the same Box Enterprise.
These are users that belong to a different enterprise and are invited to collaborate on specific files or folders. Since these users are external, the amount of information that you would be able to retrieve about them is limited for privacy and security reasons and you would never be able to generate a token from their perspective. Largely one of the few interactions that you may have from an API perspective with an External User would be removing their access to the specific piece of content.
In summary, the different user types here all fall under the umbrella of users that log into Box with an email and password and as such, tokens from their perspective can be generated either with both User Authentication and Server Authentication types as long as you have sufficient application scopes selected.
Application Users in Box are a unique user type that do not have an actual log-in into Box itself. They are considered Application Users as they are generated by applications programmatically — rather than an Admin adding the accounts — and have an ownership relation both to the enterprise and the application that created them. Since they have no access if they were to go to the Box web application, these user types are meant for purely programmatic interactions with Box or to create custom experiences in third-party applications without the users necessarily knowing they have a Box account behind the scenes.
This app user type is akin to a Co-Admin level account that is automatically generated when an Admin has authorized a Server Authentication application type. If the application scopes allow for the app to create new users, this is the persona that would be utilized from an API perspective to perform those actions. It still functions as a normal Box account from the perspective of being able to own content, create collaborations, etc., but where that user experience takes place is often outside of Box. These users have a unique email address created for them that identifies them as this user type, and what application they were created for. From an API perspective, only the application that is tied to this account or the main admin of the enterprise may be able to generate a token to impersonate this user.
This is a term that we utilize for users that do not need any elevated permissions and just need to interact with Box in the typical fashion. They can be considered a Managed User from the above list, with the only difference being that again, they do not have a way to log into the Box web application directly. These users are often utilized as a method to bring the rich content experiences of Box into other applications without requiring that a user signs up for their own Box account. This reduces the overall friction as these accounts can be spun up really quickly through our API as needed.
These two types of users are most closely related with the two Server Authentication types — JWT and Client Credentials. Since they do not have a way to log into Box directly, which is required for the OAuth 2.0 method to work, they are limited in regards to what authentication type you use to access these users. In addition, since there is an ownership relationship between the application and the users, these two user types are most often created and managed by one application rather than multiple applications trying to gain access.
For any questions, please contact our Partners team at email@example.com