Box provides two ways to authenticate applications that require org-wide access to data in a Box Enterprise organization:
- OAuth 2.0: This is the standard OAuth 2.0 three-legged authorization flow used by several APIs on the web. A Box admin can grant access to all user data in the Box account.
- OAuth 2.0 with JSON Web Tokens (JWT): This allows an application to generate a JWT assertion signed with an RSA key-pair to directly authenticate with Box.
Kloudless supports both authorization mechanisms for accessing org-wide data as a Box admin. The benefits to each approach are detailed in the Box docs. However, application behavior varies depending on the authentication type. Some of the differences are detailed below.
The OAuth 2.0 flow requires the Box user (or admin, in this case) to proceed through the three-legged authorization flow via a web browser. The authorization code obtained after the redirect back to the application server is then exchanged for a Bearer token to the user’s account.
JWT-based authentication skips requiring the admin to proceed through the web OAuth flow to grant the application a Bearer token to the Box account. The Box admin instead grants access to the app via the Box Enterprise admin console’s business settings.
Accessing individual user data
Access tokens obtained via both JWT applications as well as OAuth 2.0 apps can be used to access individual user data using the As-User header provided by Box. Kloudless exposes this capability via the “X-Kloudless-As-User” header which accepts the ID of any user in the Box tenant (API Docs).
However, JWT applications also have the option to generate per-user access tokens. To do this, add the following claims to the JWT payload as documented here:
Both approaches have their own drawbacks:
- Co-admins cannot impersonate other co-admins or admins using the As-User header.
- Box discourages generating large numbers of access tokens via the JWT-based approach, so make sure to cache or store the tokens generated for each user rather than generating them per request or group of requests.
Level of access to externally owned data
One other difference between the authentication methods is the level of access to data shared with a user in an organization by an external user.
When using the As-User header or simply accessing data as an admin, access to the metadata of folders shared by external users with a user is restricted. Box’s implementation ensures that an administrator does not have complete access to an externally owned folder if the administrator wasn’t the person who was explicitly collaborated into the content. In general, an administrator will be able to see that an external folder exists, but not be able to get all the details about that folder or its content.
When contacted, Box explained that the restriction above was implemented with the standard web UI in mind. An administrator with adequate control over users’ credentials could easily log in with a user’s credentials to obtain that access. A programmatic version of this is to use OAuth 2.0 with JWT as described above to request an access token for a user directly. Box explained that the reasoning here was that there were more layers of pre-authorization involved with the enterprise that made it appropriate to allow access to externally owned content via the user token.
Check out the Box docs on Auth Types here for more information on the different authentication models Box supports.
The Kloudless unified Storage API offers an abstraction layer that handles the maintenance and implementation of over 25 different cloud storage provider APIs, including the different authentication flows described above.
Some other cloud storage providers with JWT authentication that Kloudless supports include G Suite and Office 365. The benefits of those implementations are similar to why Box chose to adopt this approach.
To learn more about authentication strategies to give your application a high level of product differentiation, go check out our official guide to API integration now!