Welcome to the new Box Support website. Check out all the details here on what’s changed.

Best practice for allowing app users outside our organization to access folders and files with SDK

Answered
New post

Comments

8 comments

  • LoCortes

    Good morning ,

    I think that the best approach is to share a JWT with them but not the same as you are using.

     

    As per what you are explaining, I have the feeling that you are thinking on creating a unique application and us the same JSON configuration with your external clients. That, I agree, would be risky.

     

    But, why not creating as many applications as clients you have? You can configure each application with a different level of security and generate different public / private keys. Even you can disable a couple in any suspicion of risk.

     

    Also, you can create your own folder structure and assign there some application users with only uploader permissions so you ensure the safety of the content.

     

    Hope this makes sense and helps you.

     

    Thanks

     

     

    0
    Comment actions Permalink
  • cbetta

     thank you for reaching out. I love this question as it shows that you’ve already been working on something pretty exciting.

     

    As you highlighted, sharing your JWT key with your external collaborator is a clear security issue, and we would recommend against this. 

     

    Conceptually, you have two options:

     

    1. Use one code-base (application), and authenticate to Box using one set of JWT credentials. You could then have all users authenticate with your app using regular OAuth2 (not JWT) to verify who they are. This seems to be contrary to what you seem to do though, so alternatively: 
    2. Use two code-bases (applications), each belonging to a different enterprise, and each authenticated with its own JWT credentials. Folders can then be created and shared with the users of the other enterprise.

    Would #2 be an option for you?

    0
    Comment actions Permalink
  • cjacobus

    Thanks for the replies/suggestions  and .

    To summarize, we could

    1. Create separate applications per outside client and provide each client their own JWT. We would manage each client through these applications. As the application admin/owner, we would of course have the JWTs for all of our clients and would use the appropriate JWT per client when collaborating.

    2. Alternatively (but not really meeting our requirements) we could have each client create their own Box account and then collaborate with them using built-in collaboration features.

     

    Would another option be?

    Have the user authenticate through us using the credentials they have with us. Once authenticated, we generate a Box user token for them. (We will have mapped the application user to their Box app user.) Provide them with the just-generated Box user token. Using this token and the Box API key, which we will have previously provided to them, should they be able to successfully authenticate with the Box API?

       Example: curl https://www.box.com/api/2.0/folders/0 \
       -H "Authorization: BoxAuth api_key=API_KEY&auth_token=THEIR_AUTH_TOKEN"

     

    Box identifies the API key as "the client ID specific to the app and should be provided by the developer of the app".

     

    Is this enough to authenticate the user via the API? Is this the intended use of the API key, or is each client intended to be managed via a separate application per suggestion #1 above?

     

    Thanks!

    0
    Comment actions Permalink
  • cbetta

     I want to take a step back to understand what you are trying to solve here exactly.

     

    Do you expect your clients to write any code to integrate with Box? Or do you simply want to find a way for your code (your application) to be able to store files belonging to your clients in a secure place on Box, seperate from files that belong to another client?

    0
    Comment actions Permalink
  • cbetta

    Also, to follow up on your last question in the previous post, i think you are missing a slight point.

     

    Generally, there are two parts to using our API: authorization and authentication. In the first part, you generally exchange some credentials for an access token. This can either be an API key and secret in combination with client-side authentication (OAuth2), or a JWT key-pair without client-size authentication. 

     

    Once you have an access token, you can make API calls on behalf of the authenticated user as follows:

     

    `curl -H “Authorization: Bearer ” https://api.box.com/2.0/folders/0`

     

    As you can see, once authorized, the authentication for each API call only required an access token.

     

    ——

     

    Now to bring this back to your question of how to authenticate. You could either get an access token by asking a user to log into your app with OAuth2. At the end you would have a token that would allow you to push content into their user account in their enterprise.

     

    The alternative is to use JWT authentication in your app and to create a Box App User for each user that you have. You can then use JWT to authenticate as that App User every time you want to act on behalf of a specific client of yours. You would need to keep a table to map your customers to a Box App User ID, but then you can store your customers data into separate user accounts.

    0
    Comment actions Permalink
  • cjacobus

    We expect our clients to write code to integrate with Box. (We might provide code samples, as it would be fairly boilerplate given the limited integration scenarios.)

     

    In the ideal world (I think), we would create app users for each of our clients and provide each of them their own JWT. And we would integrate with Box using our own JWT. Collaboration would be achieved through shared/managed folders.

     

    Thanks for your interest and help!

    0
    Comment actions Permalink
  • cjacobus

    Thanks for confirming. I just tried this as well and confirmed the same. Trying various methods to make sure we're not overlooking something. Thanks!

    0
    Comment actions Permalink
  • cbetta

     I’d highly advise against this route as providing others access to your JWT credentials opens up your entire enterprise to the holder of those credentials. 

    0
    Comment actions Permalink

Please sign in to leave a comment.