I'm new to the OAuth Authentication process so be gentle:
Goal: To create an embedded application on a device that will integrate with Google Drive, Dropbox, One Drive, Box to retrieve & store documents. This can be easily accomplished with OAuth2 authenticaiton.
Problem: The devices have limited input capabilities (and no browser) that prohibit users from being directly redirected, for them to input username/pass on the device.
Research: I've noticed looking through the documentation for these APIs that Google provides something called OAuth2 For Devices which allows the device to request a "User Code" when they first attempt to use the application on the device. The user can then go to a computer, navigate to a specific URL, and input that code to authorize the device to access their account. This circumvents to need for user input, or a browser at all, on the physical device.
Question: Do Dropbox, Box, OneDrive, or any others allow for this type of functionality, or anything comparable? As far as I can tell Google is the only one supporting this type of workflow.
Recently i've researched the same question and i've found out that while Google Drive Api supports OAuth2 flow for limited devices, it supports a very limited set of scopes. It means that Drive api for limited devices can offer only application data synchronization (files uploaded by app), because it won't find any files created by the user (outside of application, i.e. from web) even in a dedicated application folder. (assuming that user understands that application owns that folder and everything placed there ideally should be accessible by that)
By 2022, i've found the most promising api is from Koofr which doesn't have such limitation for devices and bundles multiple cloud services into one package.
Their documentation doesn't mention support for limited devices, yet it's fully working and can be found in their online HTTP api test suite.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
When I sign in an app via Dropbox, it says:
ABC would like access to its own folder, Apps › ABC (emphasis mine)
This is to sign, that the app, ABC, can access only its folder.
However, this folder is normally visible in the Dropbox directory and synced.
Is there a way to achieve this with Google Drive? It seems like using the app-specific data feature prevents users from using the directory in any way except the app. Granting a permission to use the whole Google Drive gives the app way too much permissions. Dropbox has this feature done well. IS there a way to do a sing-up process this way with Google Drive?
When your ABC app calls Google Drive APIs on behalf of a user, you're going to be using oAuth to authorize ABC. From Drive API v3 docs:
The details of the authorization process, or flow for OAuth 2.0 vary somewhat
depending on what kind of application you're writing. The following general process
applies to all application types:
When your application needs access to user data, it asks Google for a
particular scope of access.
Google displays a consent screen to the
user, asking them to authorize your application to request some of
their data.
Google Drive's resource authorization scheme includes a number of "permissive" scopes where your app can (for example) request access to the user's entire Drive and "narrow" scopes. In the latter case your app is restricted to certain Drive files and/or folders. In late 2018 Google announced Project Strobe that promised to tighten restrictions around "permissive" scopes for many Google services, including Drive. In May 2019, they rolled an updated policy for Drive APIs:
With this updated policy, we’ll limit the types of apps that have
broad access to content or data via Drive APIs. Apps should move to a
per-file user consent model, allowing users to more precisely
determine what files an app is allowed to access. This means that only
certain types of apps can request restricted scopes from consumer
Google accounts. As always, G Suite administrators are in control of
their users’ apps.
The more user-friendly, narrower scopes are tagged and referred to as Recommended throughout Google API docs. For Drive you have 3 recommended scopes :
https://www.googleapis.com/auth/drive.appfolder Allows access to the
Application Data folder
https://www.googleapis.com/auth/drive.file Per-file access to files
created or opened by the app. File authorization is granted on a
per-user basis and is revoked when the user deauthorizes the
app.
https://www.googleapis.com/auth/drive.install Special
scope used to let users approve installation of an app, and scope
needs to be requested
Your use case could fall into either drive.appfolder or drive.file scope. drive.appfolder works well if you're looking to store app-specific data that the user won't and shouldn't touch:
The application data folder is a special hidden folder that your app
can use to store application-specific data, such as configuration
files. The application data folder is automatically created when you
attempt to create a file in it. Use this folder to store any files
that the user shouldn't directly interact with. This folder is only
accessible by your application and its contents are hidden from the
user and from other Drive apps.
The application data folder is deleted when a user uninstalls your app from their
MyDrive. Users can also delete your app's data folder manually.
drive.file is applicable if your use case has to do with some data being created by your app on behalf of the user and the user or other users should be able to see/edit/share these documents. The issue with drive.file is that it only applies to "objects" your app creates. If your ABC app creates folder Foo and then creates some files within that folder, your app will be able to access the folder and these and only these files.
With drive.file there's no parent/child ownership semantics and no propagation of permissions from parent to child. The user (in their own browser without your app) could create more files in the Foo folder but your app won't be able to read them.
It's worth noting that drive.file is not granting access to a particular folder...but it sort of amounts to an equivalent end result for a to-be-created (by your app) folder or folders.
If you're looking for a way to get access to an existing folder, you may want to look into one of the Sensitive or Restricted scopes. Using one of these scopes requires your app to go through a security review.
Most apps only have permission to store data in the Application Data folder
There is more information about API permissions at About Authorization
The drive.file scope might work for some since it appears to give access to individual files that the user OK'd. How does the user OK a file? According to the post below, they would send a file from the Drive app to my app.
So, unlike Dropbox or OneDrive, Google Drive has only 2 types of permissions: Drive or Drive.File. Simple!
What is the best way to do this. I can not find a link. Almost every example is using OAuth2 and native app version of the examples still wants the client app to pop up a browser.
My system does not have a browser. I can make REST requests but that is it.
I just want to use a simple client that can list things on a command line app just by using Outlook.com or Hotmail account. Not for a Work/School account (no Active Directory).
Long story short I don't want to be redirected to a website. I can make http request and parse the response.
These are my limitations. All implementations are in C or c++. Are there an examples with flow diagram?
Technically what you're looking for is the client_credentials grant. You can read about setting this up # Get access without a user.
This grant has some limitations. In particular, it only supports Work/School Accounts. This is because your application will require the consent of an administrator, something not available with a personal Microsoft Account (Outlook.com, XBox Live, etc.). You'll need an Active Directory to authenticate against. You can however set up Azure Active Directory for free.
I'm creating a simple iPhone app. The basic premise is that the app will display some data (That I provide online) on the application. The data changes over time, so the app has to draw the data from online and display it. I don't have a significant programming background so I don't want to use my own server.
Thus, I thought it would be significantly easier to just put the data into some documents on a Google account and then access them programmatically via the Google Drive API. I could then update the data in my Drive account and it would get updated in the application. The key here is that I am ONLY accessing ONE account that I own MYSELF. The users' accounts are not being accessed. Therefore the goal is to never have to log in manually. It should all happen behind the scenes, aka, it should look like a server, not a google doc.
With this in mind, it doesn't make sense to show the Google Accounts sign-in page to my users as the standard OAuth2.0 tutorial shows here:https://developers.google.com/drive/quickstart-ios#step_1_enable_the_drive_api
I should be able to access my own data by somehow hardcoding in my username, password etc. Google agrees here: https://developers.google.com/drive/service-accounts#use_regular_google_accounts_as_application-owned_accounts
The above link mentions a "refresh token" that I'm supposed to save. However, I have no idea how to build and save that token, or even for that matter, where to find it.
I've gone through both the basic tutorial and the Dr. Edit Tutorial for iOS, but they both assume that the application is accessing USER accounts not application-owned accounts.
I'm not asking for someone to write the code for me (though tidbits are nice), but if you can point me to a step-by-step guide or related sample code that would help me get started that would be awesome. I'll even come back and post the code that I use!
EDIT: Since I realized that the Google Drive API wasn't something I could use for what I am trying to do, I eventually found Parse which is an awesome tool that handles all the server backend for me and is free at the basic level.
Google APIs objective-C client library doesn't support service (application-owned) accounts, because they are supposed to be used by a server-side apps, instead of clients -- you shouldn't be distributing your private key as a part of an app.
If you would like to distribute content from a service account, maybe you should write a server leg to do the authentication and pass clients credentials in a secure way for them to talk to the API on the behalf of the service account. Or, use Web publishing to make documents universally accessible without authorization and authentication if privacy is not a concern.
I have a mobile web app/site and I would like the users to upload a word document to our site.
As safari on the iPhone is not able to upload files what are the alternatives?
I have seen http://code.google.com/p/iphone-photo-picker/ however this is not photograph.
Is it documented anywhere that the Dropbox API, iCloud API or another API would allow selection a file from a user to copy to our servers?
Alternately is there another way for our iPhone users using safari?
No, iPhone does not offer input type file on it's browser (except for images or videos).
What i do is, have users to send file(s) via email to site and download it programmatically on the server side and assign it to user's account either according to email address or some sort of password in the email.
Investigation has shown that the drop box API for the user so select a via on the webpage using OAuth could be an option in the future.
However the dropbox api documentation at the time of writing says:
Web applications using the Dropbox API are currently not officially
supported.
iCloud API is in beta and only available to members of the iOS and Mac Developer Programs so I am unable to review it's possibilities.
Update: I have now found this site: http://filepicker.io that handles uploads from facebook and dropbox.