Does box.com support 'Autonomous Client' or client credentials grant?
I need to generate access_token programmatically and cannot do the web-server flow.
Can we obtain the access_token using the 'Autonomous Client' or 'client credentials grant' method for box.com APIs?
Box supports a client-credentials grant, but only for access to information that would be available for an anonymous user. It can be used to download openly shared content, or to get information about your application.
For machine-2-machine integrations with Box, Box recommends creating a system-account, and signing in with that account once through the user-flow. If you put the resulting Refresh token into a bootstrap location for your application (like a config file, or a database entry that's used only once) then you can bootstrap your application.
Related
I am trying to offer an application which is to allow access to user's private files through proprietary back end and present them in a custom Web UI. What is the mechanism that allows to bridge the Web-based OAuth to the server side Drive access for each user?
EDIT:
To expand on my brief description, I would like to add that the OAuth authentication to receive the Token Response is to happen through the HTTP interaction and be presented to a user in a Web interface and be of 2-legged nature. But then I thought the Token Response would be passed to a Java server (via HTTP headers), which would process the file to be stored in user's Drive after some processing. What is not clear to me is what APIs are used to manipulate the files in Google Drive from the Java server back-end and how the Token Response is passed to those APIs to facilitate OAuth authentication.
Is this even implementable?
I have created a web app which is making use of Google Drive API/ REST v2 (https://developers.google.com/drive/v2/web/about-sdk) to perform actions such as create/update/rename/delete of documents etc.
I am authorizing requests with OAuth 2.0 (client side - that means every access token is valid for ~1h and then silently I am getting a new token) and then perform previous actions using that token.
I have a new requirement for the authorized user to share his/her documents for writing/updating them (I found out that API has option for inserting permissions (https://developers.google.com/drive/v2/reference/permissions/insert : role: writer, type: anyone).
Is it possible for a non-authenticated user to be able to write/update documents (programmatically - via Google Drive API v2 or another API?) that have been created from the authenticated user that shared these? (something that is similar to google docs/ sharing when a user is sharing his document and offline users are able to edit it?
Thanks.
Is it possible for a non-authenticated user to be able to write/update documents (programmatically - via Google Drive API v2 or another API?) that have been created from the authenticated user that shared these? (something that is similar to google docs/ sharing when a user is sharing his document and offline users are able to edit it?
What you are describing here is something called a service account. Service accounts are like dummy users. You can share a file on your Google drive account with the service accounts email address and the service account will then have access to that file. Assuming that you gave them edit permissions it will be able to read and write to it without authenticating.
Note: service accounts do not work client sided you will need to use a server sided language to use service accounts.
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.
Is there any available SDK of Twilio or Authy to use for Two Factor Authentication with Cognito?
Or What are the best practices to do User Authentication via Cognito with Two Factor Authentication?
Basically how mobile app authenticate user with Two Factor Authentication by using Cognito for Identity Management?
One important clarification - Cognito doesn't manage users for you. Cognito leverages public providers (facebook, google, amazon, twitter, an existing external provider...etc.) to generate AWS credentials for whatever user 'signs in'. Additionally, there isn't a native MFA mechanism in Cognito as of now.
With that in mind, it should be possible to do it yourself, however you would need to build some additional mechanism. Say you were trying to log into facebook - the common flow would be to:
1) open up app
2) click sign in button
3) sign in to facebook
4) app validates login with facebook, gets generated token
5) app gives generated token to Cognito, gets an id and credentials.
To catch the login event, you would need some kind of back end that intercepts the login event and has some kind of mapping of login to means of authentication, then once that provider approves the login, you can trigger the auth text/push notification...etc.
Update: this is no longer true, the Cognito User Pools service does manage users for you and allows SMS MFA for authentication.
We used to have an application connector implementing the Document List Service v3 to upload documents to users account. Now that the service will be discontinued starting as of next Monday and we need to migrate to the Drive API/SDK we have the problem to migrate our current login schema .. we are unable to use the OAuth 2 protocol and we need to authenticate users with their username/password credentials.
DocumentsService myService = new DocumentsService("xxx");
myService.setUserCredentials(username, password);
The reason is that our application scans and processes documents asynchronously from MFD devices (printers) and all processing/storage job is done in a different moment on processing servers, thus the limitation that the processing service cannot ask any consens to the user.
We do the same for other online cloud storage application (e.g. Dropbox) where they allow special 'OAuth 1' schema on request for such 'enterprise' situations.
How can we do this with the new Drive API/SDK? I couldn't find anything about that in the documentation rather than the service account, also looks like not suitable.
What you need to do is request authentication from you user once. The server gives you back a refresh token. Your automated application can then use this refresh token to get a new access token. You only need to ask the user one time for authentication. Then everything can run automated.
A service account wont really work in this instance because its meant for use with an account that you the developer own not a users account