box api v2: scope option "manage an enterprise" - box-api

What exactly is possible using the "manage an enterprise" scope in an application?
I have a client asking if it's possible for an app to access the event feed (and the corresponding files) for an ENTIRE account without a single user needing to have access to every file in the account. Would enabling the "manage an enterprise" scope grant an app this kind of access/functionality?

This is our fault for not providing enough detail. 'Manage an Enterprise' provides access to all of the methods available under the users endpoint as well as admin_logs.
Note that while this scope enables access to these capabilities, only certain user types (i.e. admin, coadmin) have these capabilities.

Related

CrossClient Authorization between Server and Gmail Addon

Background:
This is about using a Gmail Addon created using Google App Script.
When the user installs the addon, there is the OAuth Consent Screen where user provides his consent to allow the "Product name shown to users" (as configured in the OAuth Screen) to allow the access specified.
Now, I read : https://developers.google.com/identity/protocols/CrossClientAuth
which states :
When a user grants access to your app for a particular scope, the user
is looking at the user consent screen, which includes project-level
product branding that you set up in the Google API Console. (For
information about setting up the consent screen, see Setting up OAuth
2.0 in the API Console help.) Therefore, Google considers that when a user has granted access to a particular scope to any client ID in a
project, the grant indicates the user's trust in the whole application
for that scope.
Now, I have a server web component (a lambda) (belonging to the same product) that needs access to the user's email same access that the user provided after installing the addon ("Authorized Access" button).
Question(s) :
Is there a way to have cross-client (a backend server and a gmail addon) in my case to have the backend to just get access to user's data without triggering additional (basically whatever the user has provided consent to)?
Note: Using an additional authorization screen triggered manually using the GAS OAuth library I was able to get the "Auth Code" which I pass to the server using which the server now has access to the consented data (we have used the same client id and secret). However, the problem with this approach is :
User gets 2 emails about the permissions granted. Addon and Manually triggered flow.
User has to authorize the gmail addons for first access and then another which I trigger manually.
Even if there was a way I could get the "Auth Code" when the user installs the addon that would also do.
Apologize in advance there is a lot of scattered documentation and though I went through many it is likely I may have missed something.
We only issue one authorization code (refresh token) in exchange for one user authorization/approval. Your app can get new access tokens on android or web without a user approval. But if it needs a refresh token again, user still need to approve the request.
So if the addon can talk to your server, you could give it a short lived access token or will need to user authorization.

What is the intended use case for app auth and app users?

I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.

How to grant a regular user limited adminsdk access for a google app script?

Is it possible to have a regular user access the AdminDirectory.Members.List() function using google app script without making them an administrator?
It depends on how it's used. You can deploy your script as a web application, executed as yourself and give access to people people within your own domain.
You could set restriction to particular people within your own domain by using Session.getActiveUser() to determine who is accessing it. This won't work unless the user is a part of your own GApps domain.

Google Drive API grant access without manual authorization

I am building a web application which facilitates its user to upload different types of documents. All users can see each user documents in one place. Now if a user wants to access another user's document, he should not go through all the normal manual process of authorization that is carried out by Google. He should just get access to that document. I have seen this functionality in the alfresco CMS that users can see and grant access without manual authorization. Let me know how I can get this facility.
Perhaps business accounts are what you need. Users within the same domain are able to access each others documents after the regular authorization flow.

What causes a Google Drive application to request permission to "Perform these operations when I'm not using the application"

When creating Google Drive applications there are a number of permission "scopes" that can be specified to indicate to the users what permissions are required to run that application.
One of these permissions:
Perform these operations when I'm not using the application
Causes a lot of concern amongst our users. We could not find any definitive explanation of what causes this permission to be listed.
The only possibility we could think of is that using server-side flow for the OAuth2 means that the server might be still syncronising after the browser has been closed and so this has to be flagged up.
If that's the case, will using JS direct to Drive (no proxy server) mean that this permission will not be requested?
This is due to the OAuth2 flavour you chose.
You probably have taken the web server flow flavour, which build a grant URL with the parameter access_type = offline.
This allows you to obtain a refresh token, so you can access your user's files after he has used your app.
You can replace this access_type paramater to access_type=online but you wont get a refresh token. You will be able to acces your users'files only for one hour. After that, you will have to request a new access token to access his files.
I encourage you to read this page where each of the flow are explained.
The official specifications are a good source of information too.