According to the new Gmail OAuth policies, certain authentication scopes require a new App Review process.
I want to replace the restricted scopes I'm currently using with just one non-restricted scope.
Does this mean I can simply skip the verification process? Or does this mean other granted scopes like the one from drive ('https://www.googleapis.com/auth/drive') will be revoked or will my app will get an "unverified" screen?
According to the FAQs, you do not need to request for verification if your app is 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.
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.
As for your second question, if your app uses sensitive scopes or does not fall in the above scenarios, then yes, your apps will get the Unverified App screen.
If you don't publish your app for review:
If your public application uses sensitive scopes that permit access to
certain user data, users of your application might see anUnverified
App screen.
To protect users and Google systems from abuse, applications that use
OAuth and Google Identity have certain quota restrictions based on the
risk level of the OAuth scopes an app uses. Failure to get your app
verified might result in your project quota getting exhausted. Learn
more about Unverified Apps.
You can visit the FAQs if you have other questions.
If you request scopes that Google considers sensitive, you will most likely be denied approval. It is better to limit the scopes that you request to just the ones for identity.
If you don't your app will have this big warning that your app is not trusted while you wait for approval. Then your app will be denied.
Eliminate scopes until the request approval button is disabled. Once your scopes are limited to the point that Google does not require approval for your app you will be OK.
Please ensure you have added all the scopes used by your app on OAuth Consent configuration screen in Google Cloud Console. Once you have done that, screen should flag you the scopes which need to go through verification.
Even if your app doesnt use any restricted scopes, it may be using some sensitive scopes for which you will have to go through OAuth verification process.
Hope this helps.
Related
The Microsoft docs state:
Registering your application establishes a trust relationship between your app and the Microsoft identity platform. The trust is unidirectional: your app trusts the Microsoft identity platform, and not the other way around.
What exactly is meant by "trust" here and how does the app registration establish said trust?
The way I understand it the registration basically makes the app known to the AD, but how does that make the AD, the app is redirecting to for interactive logins, more trust-worthy to the app? Couldn't a malicious AD just pretend to know any app that's using it for logins? Wouldn't it need some kind of shared secret to assure the app that the AD really is the AD? And isn't HTTPS establishing that trust already?
It makes more sense to me the other way around: the AD receives a login request along with a redirect URI set by the app. But if the redirect URI is not known to the AD then the request is not trust-worthy and will be rejected.
I'm probably misunderstanding something, so could someone please explain the idea behind this?
In authentication world trust is a complicated word. In my opinion, the easiest way to approach this thing is taking the Google Sign-In -button as an example. You can use it to log in with your Google account on almost every website out there. Does this mean Google trusts every website out there using it? No, of course not. Do those websites trust Google? Sure they do, they have no visibility if Google returns the correct information about the users to them.
The case is very similar here as in most cases you will be using the same protocol to implement it (OAuth2 OIDC).
You are correct, you need to configure secrets & returnUrls to make sure that the App Registration is not used for malicious purposes, however, this does not create trust between the identity provider and the application. It's just technical measures to protect the client.
However, you can of course trust the application if you want to. The most common way is to grant it access to scopes so the application can do actions on behalf of the user. Usually this is done by those consent screens you probably know ("grant access to your email and phone number"). In enterprise setting, they are often omitted and access is granted with admin constent.
TL;DR; There is no inherit trust just because there is an App Registration, however you can trust an app to access user data.
I have the following access policy configured that should blocks access to Microsoft Teams, if there is no valid client certificate:
This policy works in the browser, when teams.microsoft.com is opened (including logging in with valid crendetials) with the custom error message:
Yet, while using the Teams Desktop App, the affected user can login and use teams even without the certificate. The message in the Activity Log of Microsoft Cloud App Security states "bypass session control".
How does the rule not affect the Teams App but work in the browser.
The teams app cannot have access to a certificate, because I tried it in a Sandbox.
As well as the bypass info must mean, somewhere a bypass is allowed/configured? But where would I find that?
If you extend the policy to also check the Client App both for Browser and App, then also the Teams App will be blocked by the policy (or not if the certificate is available).
• You are able to access Teams client app on desktop because you have not selected filters that include ‘client app equals to Mobile and Desktop’ in Access Control Policy as below.
• So, once you select the filters as per your convenience, as above, and the actions to take as ‘block’ or ‘test’, the desktop teams will not be able to start up. Also, the ‘bypass session control’ message in the browser while accessing a blocked or restricted site is displayed in activity logs in Microsoft cloud app security because you might be having ‘admin’ level access to modify, create or delete any access control or session control policy in there.
Please find the below links for more information: -
https://learn.microsoft.com/en-us/cloud-app-security/manage-admins
https://learn.microsoft.com/en-us/cloud-app-security/troubleshooting-proxy
I need to get access at the sheets and I am following this guide to start to do that https://developers.google.com/sheets/api/quickstart/nodejs
But the button that enables google APIs doesn't work, all names I put on the project return an error.
I went on the API console and created a new project but I do not know how to get credentials files (if they are needed) and then I must create an URL for the OAuth page?
How to get OAuth crendetials manually
There different types of crendetials and the procedure to obtain them is slightly different depending on your situation.See here for the different scenarios.
In most cases (an exception is when using a service account), the first step is to set up an OAuth consent screen.
The consent screen is the screen your users see when they are prompted to agree to terms that are presented to them by your application
To set up a OAuth consent screen, go after chosing a project from the GCP console on APIs & services -> OAuth consent screen
You need to chose either your application is supposed to accessible only by domain internal users or also external (in the latter case you might need to submit your application for verification by Google, pontentially involving costs - depending on the scopes you use).
You need to provide an application name that your users will see (the logo is optional)
You need to specify which scopes your app will use
You can specify other properties, e.g. the Authorized domains (this is usually your website from which the users will be redirected to the consent screen when performaing some kind of action)
If you are not sure about the optional properties, leave them out for the start
Once you set up the authentication screen, the second step is to go on APIs & services -> Credentials
Read the Authentication overview to decide which credentials you need
For most applications you will want an OAuth client ID
The diffrent Application types are described here, to start with create a Web Application
Authorized JavaScript origins and Authorized redirect URIs is basically your Webpage from which the users will be redirected to authenticate and to which they should be redirected after authentication.
For local testing you do not need to specify those URLs
Once you create the OAuth2 client successfully, you will obtain the Client ID and Client Secret - your crendetials to incorporate into your code when using Google APIs.
If you click on the download button on the right side of your newly created credentials - it will generate a json file on your local machine from which the credentials will be read automatically if you follow the quickstart.
Alternatively you can paste the credentials directly into your code - see here for sample for different situations
I have a nodejs webapp with many users with a custom login process. I would like gitlab to accept that authentication and not force users to create a new app. What is the best way to accomplish this?
I would go for OAuth 2.0 Single Sign On (SSO). Below you can find the architecture diagram taken from here. As you can see the client is redirected to log in in the OAuth2 provider to get a valid token for authentication. The OAuth2 server must be configured for the application requesting access including the secret, the client id and the callback URL.
You can configure GitLab CE to sign in with almost any OAuth2 provider. Only be careful with the limitations:
It can only be used for Single Sign on, and will not provide any other access granted by any OAuth provider (importing projects or users, etc)
It only supports the Authorization Grant flow (most common for client-server applications, like GitLab)
It is not able to fetch user information from more than one URL
It has not been tested with user information formats other than JSON
You also need to configure your node js web application as an OAuth2 server. There are npm availables with the source code here.
Recommendation
I would install some open source Identity Management to separate the user management from your webapp, provides better integration with other third parties and forget about encryption and other stuff you need to take care in your webapp. There are multiple options such as KeyCloak for instance.
You have to define a dedicated user , and use the private_token of this user to login for ALL users that will use your application.
The restricition would imply all users will have the same rights ....
The other solution is to use the Private Token of the user at login. In this case , only the rights of these particular users will be used.
Firebase provides database back-end so that developers can focus on the client side code.
So if someone takes my firebase uri (for example, https://firebaseinstance.firebaseio.com) then develop on it locally.
Then, would they be able to create another app off my Firebase instance, signup and authenticate themselves to read all data of my Firebase app?
#Frank van Puffelen,
You mentioned the phishing attack. There actually is a way to secure for that.
If you login to your googleAPIs API Manager console, you have an option to lock down which HTTP referrer your app will accept request from.
visit https://console.developers.google.com/apis
Go to your firebase project
Go to credentials
Under API keys, select the Browser key associated with your firebase project (should have the same key as the API key you use to initialize your firebase app.)
Under "Accept requests from these HTTP referrers (web sites), simply add the URL of your app.
This should only allow the whitelisted domain to use your app.
This is also described here in the firebase launch-checklist here: https://firebase.google.com/support/guides/launch-checklist
Perhaps the firebase documentation could make this more visible or automatically lock down the domain by default and require users to allow access?
The fact that someone knows your URL is not a security risk.
For example: I have no problem telling you that my bank hosts its web site at bankofamerica.com and it speaks the HTTP protocol there. Unless you also know the credentials I use to access that site, knowing the URL doesn't do you any good.
To secure your data, your database should be protected with:
validation rules that ensure all data adheres to a structure that you want
authorization rules to ensure that each bit of data can only be read and modified by the authorized users
This is all covered in the Firebase documentation on Security & Rules, which I highly recommend.
With these security rules in place, the only way somebody else's app can access the data in your database is if they copy the functionality of your application, have the users sign in to their app instead of yours and sign in/read from/write to your database; essentially a phishing attack. In that case there is no security problem in the database, although it's probably time to get some authorities involved.
Update May 2021: Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to your Realtime Database to only those coming from iOS, Android and Web apps that are registered in your Firebase project.
You'll typically want to combine this with the user authentication based security described above, so that you have another shield against abusive users that do use your app.
By combining App Check with security rules you have both broad protection against abuse, and fine gained control over what data each user can access.
Regarding the Auth white-listing for mobile apps, where the domain name is not applicable, Firebase has
SHA1 fingerprint for Android apps and
App Store ID and Bundle ID and Team ID (if necessary) for your iOS apps
which you will have to configure in the Firebase console.
With this protection, since validation is not just if someone has a valid API key, Auth domain, etc, but also, is it coming from our authorized apps and domain name/HTTP referrer in case of Web.
That said, we don't have to worry if these API keys and other connection params are exposed to others.
For more info, https://firebase.google.com/support/guides/launch-checklist