Skip to main content
Question

Box Authentication and connection verification

  • May 22, 2025
  • 4 replies
  • 57 views
C
Forum|alt.badge.img

Hi there,

I have two topics I'd like to inquire about which are related to each other.

Before that, a little background on what I'm trying to achieve - I'm building a Box integration which will include more than one service running simultaneously and collecting data from Box.

 

Now, my two concerns are:

  1. Which authentication flow should I use for getting access to users' content, while having different services accessing Box at the same time.
  2. How can I verify the permissions my application has been granted and essentially 'Test connection' after connecting to a user's account.

 

Now, as I understand my options are:

  1. Using 3-legged OAuth flow, which will provide me with a pair of access-refresh tokens after the user authorizes access. Using this approach I will have to share the access token between my services, and update all services after the token has been refreshed.
    Using this approach I will create the developer application and define the scopes which the user will authorize, and so when I get the access token I know that the connection has been established.
  2. Using JWT authentication flow with a Service Account, I will be able to generate as many tokens as my different services need. So no headache with populating the refreshed tokens to all of my services.
    Using this approach each user account will have to use its own Service Account, and I plan on delegating the service account creation process to the user. In that case I will need to verify that the service account has the required permissions.

In any case, the user can revoke the access to the dev app at any time. How can I check efficiently that the connection hasn't been broken and that I can call the required APIs, without bumping into unauthorized errors?

 

Sorry for the long post, I'd really appreciate you help and insights.

Or

 

    4 replies

    C
    Forum|alt.badge.img

    Based on the type of integration you're building, either three-legged OAuth2 or JWT server auth might make sense:

     

    Option A) If you're working with a specific enterprise or building something for your company only, and you can get the enterprise administrator to authorize your application, JWT is a great option because it will allow you to generate access tokens for each user without needing to go through the three-legged OAuth2 flow and you won't need to get user consent every time (since the enterprise admin has already authorized the app).

     

    Option B) If your app needs to be able to integrate with personal user accounts outside of an enterprise, or you can't get the enterprise admin to authorize your app, you'll have to use three-legged OAuth2.  Many companies block applications by default, so even building your app this way doesn't guarantee that you'll be able to integrate without action from the enterprise admin.

     

    Regarding testing the permissions of your app or the validity of your access token, there is not a way to test whether or not the access token is valid besides just making the call and checking for a 401 Unauthorized error.  If you're using traditional OAuth2, you'll either need to use the refresh token to get a new access token (if the app is still authorized and the user hasn't revoked access), or you'll need to send the user back through the authorization flow to reauthorize your app with updated permissions.  If you're using JWT auth, you can simply generate a new access token for the user, provided that the enterprise admin hasn't deauthorized the entire app.

    C
    Forum|alt.badge.img

    Thanks for your answer!

    My integration will always be with an enterprise/business account, having the admin authorize access to the application.

    Considering this, I'd appreciate it if you could establish the following for me:

    1. Connection testing - In any case, to check if my app is still authorized I would just need to generate an access token (either by using the refresh token in the 3 legged flow or by generating a new admin token in Service account with JWT flow)
    2. Permission scopes verification:
      1. 3 Legged OAuth - As I will be creating the developer application, I will define the permission scopes. When the admin authorizes access I can rest assured that my application has received all the required permission scopes.
      2. Service Account with JWT - Admins will be responsible for creating the service account and will provide the application with the private key for signing the requests. In such case, is there a better way for checking my application has received all the required permission scopes, besides trying out all the different API endpoints? (verifying I don't get any unauthorized errors)

    Thanks again!

    Or

    C
    Forum|alt.badge.img

    Hi,

    Any chance for help here?

     

    Thanks!

    C
    Forum|alt.badge.img

     Here are the answers to the things you wanted clarified:

     

    1. Yeah, you can just try to generate new tokens; if the app has been deauthorized, it should fail with a 401 error.

    2. For both types of auth, the scopes that your app requests should either fully be authorized, or the app will not be authorized at all.  The user or enterprise admin who authorizes your app can only accept or deny the full set of scopes your application asks for; they cannot pick and choose.  The one caveat to this is if you change the scopes that your app requests — in this case for JWT auth, the enterprise admin will need to reauthorize your application.

     

    One other thing you mentioned that I wanted to clarify is that the enterprise admin does not set up the service account or the private keys; you generate the key pair yourself when you create the application, and Box automatically creates a service account for each enterprise that your application is authorized in.

     

    In general, based on what I know about your use case, I would recommend trying out JWT auth — it will allow you to simply generate tokens on behalf of users rather than requiring manual intervention to authorize users.  With traditional three-legged OAuth2, you will need to maintain a refresh token for every user that your app is authorized as.  This can be kind of a pain, whereas with JWT you just need your app's static credentials (e.g. key pair, client ID and secret, and enterprise ID).

    Terms of ServiceAccessibility statement