I would like to create an application where I can access ONLY my own Google Drive files for programmatic operations that I perform on my own managed spreadsheets. However, on 2020 January 1st, restricted scopes are going to require verification from Google in order to use the Google Drive API fully.
How can I use restricted scopes for accessing ONLY my personal Gmail account after January 1st?
According to the OAuth API:
When can I skip submitting my app for a review?
You do not need to submit your app for review if it's going to be used in any of the following scenarios:
• The app is not shared with anyone else.
• The app is used to send emails through WordPress, or similar single account SMTP plug-ins.
• The owner and users of your apps belong to the same G Suite domain or customer. Learn more about public and internal applications. If you aren't an Apps Script developer, learn how to mark your app as internal in the FAQ How can I mark my app as internal-only?
• The app is domain installed or whitelisted by a G Suite domain administrator. If your app is intended for G Suite users, access might depend on domain administrator permission. Obtaining a verification will likely make it easier for administrators to grant access.
• The app is in development mode and not ready to be public. Note that the app will be subject to the OAuth user quota.
• The app is trying to access data from users' Google Cloud Platform project. For instructions on using a service account, see Using OAuth 2.0 for Server to Server Applications.
How can I mark my app as not being sharable with anyone else?
Google updated their FAQ, and it much more clearly delineates what is required in order to keep using Google Drive with restricted scopes:
You do not need to submit your app for review if it's going to be used in any of the following scenarios:
Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in.
SMTP/IMAP/WP: The app is used to send emails through WordPress, or similar single account SMTP plug-ins.
Internal Use: An app is internal when the people in your domains only use it internally. Learn more about public and internal applications. Learn how to mark your app as internal in the FAQ How can I mark my app as internal-only?
Domain-Wide Install: If your app is intended for only G Suite enterprise users, access will depend on permission being granted by the domain administrator. G Suite domain administrators are the only ones that can whitelist the app for use within their domains. To learn how to make your app Domain-Wide Install, see My application has users with enterprise accounts from another G Suite Domain. How does this apply to my G Suite or Cloud Identity enterprise accounts?
Development/Testing/Staging: If your app is in development/testing/staging mode and not ready to be publicly accessible, then you do not need to submit your app for verification. Note that your app will be subject to the unverified app screen and the 100-user cap will be in effect when an app is in development/testing/staging.
Service Accounts: When your app is trying to access data from users' Google Cloud Platform project and can run API requests on its behalf. To understand what service accounts are, see Service accounts.
For instructions on using a service account, see Using OAuth 2.0 for Server to Server Applications.
Related
How do I create a service account, grant the necessary permissions, and use the Azure billing APIs (usage and rate card) from the server-side of a website?
I'm looking to show expected bill on 6/7/2018 is $123.45 on an internal dashboard, mirroring the data in the billing usage graph on the Azure portal.
https://github.com/Azure-Samples/billing-dotnet-usage-api and https://github.com/Azure-Samples/billing-dotnet-ratecard-api are the samples all posts reference. The setup for each references the legacy Azure portal, and the setup instructions make assumptions I don't understand. I've not found any more recent setup instructions for using the billing APIs. In all my experiments, I've received an OAuth token, but I receive 401 Unauthorized responses when calling the actual API. (Obviously I shouldn't include my guids in this question.)
The samples identify that when creating the app, I must choose a "native application", but Scott Allen notes that "native application" requires a live OAuthed user, but my users don't have permission to the Azure portal, so I must pre-authenticate with configured settings. He recommends "Web apps / API".
The samples are vague in the permissions required. They note I should "make sure the sample app will have permissions to access the Windows Azure Service Management APIs", but from the new portal, I don't find Windows Azure Service Management APIs nor any other permissions that sound like Billing management.
When crafting the AAD App in the portal, and when starting https://github.com/Azure-Samples/billing-dotnet-usage-api/blob/master/ConsoleApp-Billing-Usage/ConsoleProj/Program.cs, each references settings such as "Client ID" and "DirectoryId" that are named differently in different places. Though I feel confident in my mapping guesses, the sample doesn't work for me, so I'm confident I've done it wrong.
I've even tried making requests directly to the REST endpoint at https://management.azure.com/subscriptions/{subscription-Id}/providers/Microsoft.Commerce/UsageAggregates?api-version={api-version}&reportedStartTime={dateTimeOffset-value}&reportedEndTime={dateTimeOffset-value}&aggregationGranularity={granularity-value}&showDetails={showdetail-boolean-Value}&continuationToken={token-value} passing in the OAuth token without success.
What did I do wrong here? How do I configure an AAD app to use the Billing APIs using pre-configured auth and subscription settings to show Azure usage details on a web page?
According to the error log, it seems you don't give your app correct subscription role. You could check this link:Assign application to role.
Note: You could give your app Owner role.
You also check this link:Authentication flow for native application to API.
Also, you also could create a web app. But you need use different way to get the token, see different check this link.
I've got the Unity Xbox Live services example up and running allowing me to sign-in to my Microsoft Account via Xbox Live services in Unity.
I've also got Azure App Services (Mobile services) running in Unity to query and persist my data. App Services supports authentication out of the box including Microsoft Account support.
Does anyone know if I can use the authentication from Xbox Live services sign-in to authentication my web calls against my Microsoft Account in App Services?
It gets complicated :) although I can understand the frustration. Let me give a quick overview, but I'm happy to give more details as needed.
When dealing with sign-in, the first step is authentication - and there are three choices on such systems with Microsoft
1. MSA, or Microsoft Account, which is what most consumer systems use, such as Xbox.
2. AAD, or Azure Active Directory, which is typically for enterprise applications.
3. S2S, or Server to Server, which is typically done either with an SSL certificate or shared secret. (Note this is also similar to the app secret mentioned above, although app secret is less secure since the secret is with the app itself, but this and MSA do go together).
These three systems are very different in goals, designs and requirements so there isn't really an option to unify them.
Now lets assume that you are using only #1 above - signing in with MSA. You might wonder why you can't take the token returned for one set of services and use it with another. Now we are into the realm of user privacy and security isolation. Have you noticed when you sign into a game on the PC with XboxLive that you get a dialog box asking if it is okay? That is the consent dialog and is required so that malicious apps can't steal a token for one part of a system (say your outlook.com sign-in) and use it to grab data from elsewhere (onedrive, xbox, etc) without the user saying "yes, that is okay". This same thing happens with systems like Facebook, etc - it is a fairly standard system.
So, to enable this, each time you ask MSA for a token, you have to specify the site you are going to use it with, so MSA knows what consent to ask for - and to ensure it stays only to that site.
tl;dr - doing security right means more hassles :) But the good news is that the underlying system should be able to detect these and prevent the user from having to present a sign-in for each site - just one sign-in, but possibly multiple consent dialogs. And more code for the developer...
Does anyone know if I can use the authentication from Xbox Live services sign-in to authentication my web calls against my Microsoft Account in App Services?
AFAIK, for app service authentication with Microsoft Account, you need to create the application in Microsoft Account Developer Center, then you need to add Client Id and Client Secret for your Microsoft Account provider under "Settings > Authentication / Authorization" of your App Service application. For more details, you could refer to Microsoft Account authentication.
Based on your scenario, you could only use the Client-managed authentication for Microsoft Account. Additionally, the app service authentication for Microsoft Account uses LiveSDK for initiating the sign-in process. Though, I'm not familiar with Xbox Live services sign-in, based on my understanding, I assumed that you could not achieve this purpose for now.
I'm developing a Chrome extension, addressed to GMail users only, which needs access to some Google APIs. I use OAuth2 for authentication and authorization.
Wanting to help Google Apps domain administrators deliver the product to all users in their domain with minimal work, I have registered a project in the Google Developers Console and published it (privately, as yet) to the Google Apps Marketplace.
The extension itself is already published in the Chrome Web Store.
With this, domain administrators can, from their Admin Console:
(a) Go to "Apps > Marketplace apps" and add our app for all users in the domain.
or
(b) Go to "Apps > Device Management > Chrome Management > User Settings" and add our extension to the "Forced-installed Apps and Extensions".
If they do (a), users who install the Chrome Extension get "one-click single-sign-on": once they authenticate to our app, they won't need to approve any permissions.
If they do (b), users get our Chrome Extension automagically installed in their Chrome browser, but they still need to approve permissions after their first authentication.
If administrators do both (a) and (b), users get the same result as if they did only (b) -- that is: users still need to approve permissions.
Is it possible to get both? That is: have the extension force-installed and the authorizations granted by the administrator?
How?
Unfortunately the Google Apps Marketplace only supports hosted applications, not extensions or packaged apps. I don't think it would be possible to accomplish what you want, at least not without two different installations.
We are using Google Apps for Business in my company and we would like to get a complete list of apps installed and accessible to an user.
I've found 4 differents types of Apps :
Marketplace Apps installed on the Domain by an Admin
Marketplace Apps granted by the user
Chrome Extensions globally deployed by an Admin
Chrome Extensions installed by the user
Am I missing something ?
From now, I've only found how to retrieve the point 2 with the https://developers.google.com/admin-sdk/directory/v1/reference/tokens/list API.
I can't found any other API to retrieve the others Apps.
Thanks for your help.
That's correct, the Admin SDK currently only provides the ability to list OAuth tokens that users in the domain have authorized on their own. Domain-wide installed applications and applications that don't require authorization (like Chrome extensions) aren't discoverable programmatically.
I am currently trying to understand the combination of Azure ACS with Claims-based Auth and the option of using a custom STS and I am only slowly getting through the (unfortunately few) info sources.
Before I spend more hours on this I would like to confirm if my plan is even possible.
I have multiple azure roles (web+worker) that are being accessed over the internet by both employees and customers. Additionally, employees access these roles and desktop apps from inside our local network.
User data comes from two sources. Our azure app has user data about customers and employees, our (local) AD only from employees.
To make the login experience as efficient (and ergonomic) as possible, when accessed via our local network, employees should be automatically authenticated (Windows Integrated Auth?) on both the desktop app (automatically because of Windows User Profile Context) and on the azure apps (hopefully w/o login page).
Customers, on the other hand, should enter their user credentials when accessing the azure app, but should not have to decide between different "Credential-sources", they should just get the username+password form.
In other words
Employee visits Azure app from local network -> Auto-login with Integrated Auth / AD data
Employee visits Azure app from internet -> Username+Password form
Customer visits Azure app from internet -> Username+Password form
While writing this question, two more came to mind:
1) Is it even possible to auto-login based on source/cookie/wizardry or would that require a manual user choice for selecting the "Credential-Source"?
2) If Azure ACS "knows" that AD account with Username X is the same as Azure App User Y, does it matter with which one logins? Can the app access the same claim-data on either login route?
Are you sure you need a custom STS? It sounds like to start you just want to enable your AD users to sign in to your azure applications using their windows credentials if they are on the domain (no password prompt). ADFS 2.0 and WIF will facilitate this. In addition, if you set up an ADFS proxy server so that when those same users browse to your app from outside of the domain they will get prompted for their domain credentials.
Now your AD users are set up, but if you want your applications to be accessible to users outside of your domain, you can federate ADFS with another organization's ADFS server, or use ACS to enable login using consumer identity providers such as Google, Yahoo, and LiveID, which are provided as built in options. If you did introduce ACS like this, you would configure your corporate ADFS server as an identity provider on your ACS instance alongside google, yahoo and what not, so that when your users browse to your site they will be prompted to select which identity provider they wish to sign in with.
Here's a fantastic whitepaper that demonstrates using ADFS to authenticate to cloud applications:
http://www.microsoft.com/download/en/details.aspx?id=13789
More detailed info about deploying ADFS (such as deploying the ADFS proxy) can be found in technet.
And for ACS, there are guides and samples on how to integrate it into azure applications, and how to add ADFS identity providers: http://msdn.com/acs
One thing that you could do is look at the user credentials when a page is requested in order to get the authentication info.
If you look at...
HttpContext.Current.User.Identity
You can get info about the user's identity. If they are on the domain you will see that they have a domain name and you could programmatically choose to direct them to a login page.
Let me also say that I've never tried to do this so I don't know if there's a built in way to do this by simply configuring something in web.config.