Box.com developer access vs application access

rahvee · January 25, 2019, 9:01pm

At present, when rclone connects to box, it uses a developer (bearer) access_token, and refresh_token to generate a new access_token when it expires. This is great, if what you want is to use rclone to access your personal box account, with unrestricted access. Things are a little different, if rclone is going to be run on a server, as a service account, that maybe you want to have restricted access…

If you browse to https://developer.box.com, login to the console, and go to Create New App > Custom > OAuth 2.0 with JWT > (enter a name), then it presents you with a temporary developer access_token (just ignore that for now). You can then browse to your app, Configuration. At the top, it has authentication methods for the developer, but if you scroll down, you can restrict the access of the app, and generate an RSA key for the app to use for authentication.

By default, even with the “all files and folders in box” checkbox selected, the app has no access to anything at all, whereas authenticating as the developer you have full access to everything. As the developer, you can query the API for app_user.id, which is of the form “AppUser_xxxxxxxxxxx@boxdev…”. Then, as yourself, you can share a folder with that user, as if it were some other box user.

For service accounts running on servers, this is highly desirable compared to using the developer access_token. The only change that rclone needs in order to support it, is to have the ability to authenticate to the box api with application RSA key instead of using the developer access_token. (And some sugar to make it easy for sysadmins to figure out how to generate the application credentials, or decide which authentication method is better for their usage).

As always, thanks for this wonderful tool.

ncw · January 25, 2019, 11:11pm

I think you aren’t the first person to bring this up - I found the issue here: https://github.com/ncw/rclone/issues/2582

Can you take a look at that issue and comment on how that might work?

Would you like to help implement this?

rahvee · January 26, 2019, 2:45pm

Thanks for that reference. I’ve looked it over, and unfortunately, I don’t know go, and I don’t know JWT. I do know a lot of other languages - python, java, C#, etc, and I know a lot of crypto, so I understand how an RSA key works, and how it’s used. I understand the terminology I read on the various linked pages, “signed json object,” “encoded signature,” “Claims,” and all the crypto components, HMAC, RSA, ECDSA, etc. I believe with a small amount of effort, I can produce an example of using JWT in one of these other languages - I guess python would be the easiest. Maybe that would be useful to serve as an example and I can offer myself as someone to talk to while you’re trying to do the same in go? If there’s stuff in the documentation that you linked to, that you don’t understand, maybe we can get on a phone or skype call and work it out. I’m suspecting that for both of us, the limitation is not so much lack of understanding, more likely time constraint. We have jobs and other stuff to do; it takes time to work on open source software that’s good for the community but nobody pays for or otherwise produces any reward except an occasional “thank you.”

If it sounds like I might be helpful, let me know which parts I could do that might be helpful…

On a completely separate note, rclone sync only can sync one-way. I previously worked on cloud file sync software and I’m intimately familiar with how to implement bidirectional sync. I like the idea of contributing to rclone, but time and language (go) barriers are in the way.

ncw · January 27, 2019, 11:17am

Go is relatively easy to pick up. If you know java you'll certainly find go familiar. It is most like an improved version of C. The go tour is the place to start if you want to have a go at learning it.

I have a sneaky suspicion that the oauth2 library supports this already. It certainly does for google drive and google cloud storage and we use this support already.

If you wanted a task, could you get your head around the jwt code here

github.com

golang/oauth2/blob/master/jwt/jwt.go

// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// Package jwt implements the OAuth 2.0 JSON Web Token flow, commonly
// known as "two-legged OAuth 2.0".
//
// See: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12
package jwt

import (
	"context"
	"encoding/json"
	"fmt"
	"io"
	"io/ioutil"
	"net/http"
	"net/url"
	"strings"
	"time"

This file has been truncated. show original

And see how that matches up with what would be required for box.

Rclone already uses this

github.com

golang/oauth2/blob/master/google/google.go

// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

package google

import (
	"context"
	"encoding/json"
	"errors"
	"fmt"
	"net/url"
	"strings"
	"time"

	"cloud.google.com/go/compute/metadata"
	"golang.org/x/oauth2"
	"golang.org/x/oauth2/google/externalaccount"
	"golang.org/x/oauth2/google/internal/externalaccountauthorizeduser"
	"golang.org/x/oauth2/google/internal/impersonate"

This file has been truncated. show original

To use JWT with google drive and google cloud storage, so all the bits must be there already, it is just a question of figuring out how to glue them together.

Thank you for your offer of some example code - I found some code examples on box's website this which seems to have it covered at that level.

I'd love for someone to take this forward. There have been various attempts in the past but not one which has made it into the rclone code yet.