I'm currently building a web application that works with the Gmail API. I'm waiting for approval from Google's security team to have a proper OAuth connection, but I noticed that users can pre-approve your application by searching within the API Controls settings by your App ID.
This setting is located in the Google Account via: Admin Panel > Security > API Controls > App Access Control.
I noticed that if a user does this before they try to connect your app it doesn't go against your 100 account limit within Google Developer Console while in beta.
My question is, could you have this as permanent solution to get around the Google OAuth application if Google never approves you? Of course, through this method the user is still giving permission, just curious if this has been done by anyone before.
Yes, this is allowed when all your users are Google Workspace users, and is listed under exceptions to verification requirements here: https://support.google.com/cloud/answer/9110914?hl=en. If your application is meant for a broad set of users, completing app verification is necessary.
Yes, this is allowed when all your users are Google Workspace users, and is listed under exceptions to verification requirements here: https://support.google.com/cloud/answer/9110914?hl=en. If your application is meant for a broad set of users, completing app verification is necessary.
Help
Related
I have developed a desktop app that uses the Gmail API to download emails from only my own Gmail account. When I try to make the app "Internal", I am told that I cannot do so, because I am not a Google workspace user. So I started the verification process and went thru the first step - the domain verification process. After this step, I received this email from api-oauth-dev-verification#google.com:
Hi,
Thank you for your patience while we reviewed your project.
It looks like your app is only used by the people in your domain, so your project doesn’t need to be verified.
(Learn more about internal vs. public users).
Note: internal use and personal use are different.
Applications for Internal Use
If this is correct, please let us know by replying to this email. We'll then close your request, and you can update your project from public to internal by following these steps:
Sign-in to Google Cloud Console
Select the project ID: getEmails (id: getemails-354519)
Go to OAuth Consent Screen under APIs & Services
Go to User Type
Select Make Internal
Click Save**
But every time I try to make the app internal, I am prevented from doing so with the same message "Because you are not a Google Workspace user, you can only make your app available to external users".
How do I get around this Catch-22 situation? Any help would be greatly appreciated.
I have developed a desktop app that uses the Gmail API to download emails from only my own Gmail account. When I try to make the app "Internal", I am told that I cannot do so, because I am not a Google workspace user.
To set an app as internal you would need to have created that app on google cloud console using a user on your google worksapce domain. You can not set an app to internal if you have created it on a standard google gmail user.
So I started the verification process and went thru the first step - the domain verification process. After this step, I received this email from api-oauth-dev-verification#google.com:
If this app is being only used by you why would you want to verify it? verification is only needed when your going to have additional users then yourself.
But every time I try to make the app internal, I am prevented from doing so with the same message "Because you are not a Google Workspace user, you can only make your app available to external users".
Again you need to login and create the app from a user on your workspace domain not on a normal gmail user.
How do I get around this Catch-22 situation? Any help would be greatly appreciated.
If its single user, and you don't have a workspace domain. Don't verify it there's no need to.
We have an existing Android and iOS application that consumes REST API from our servers. The API provides a token to the authenticated users after they log in using their credentials (username, password combo.) from the mobile applications.
Now, we're planning to create a Google Glass application for the same. In this case, we'd like to use the existing REST API along with Glass also. The Glass app will be built natively using the GDK.
My concern is, how would the users be able to input credentials? Because, users may have signed up for the service using non-google accounts?
Many thanks in advance.
At the moment, there is no supported way for apps made with GDK Early Access to authenticate the user or provide a way to connect the Glass account to your auth system. The Glass team has indicated such methods are coming, however - the Strava Cycling app, for example, does this, and it is expected that a similar feature will become widely available as the GDK matures.
Strava Cycling appears to get its credentials at the time you setup the app through MyGlass. When you turn it on it redirects you to a website to log into Strava's service before completing the install.
I just gave a talk on this exact topic at Wearables DevCon. The solution I proposed is purely done through GDK. All the user has to do is sign into their Google Account on a phone/tablet/computer and enter a code that is shown on Glass.
Check out the slides here:
https://docs.google.com/presentation/d/1NepYwlKdEvLV0QH9ix2I8l-JY1kHjBR9AXKBNpgTI6g/edit
And the code here:
https://github.com/victorkp/GlassWebNotes
The latest Glass release (XE16) publishes the remote authentication API for apps distributed through MyGlass:
https://developers.google.com/glass/develop/gdk/authentication
My team is trying to develop a product for the google apps marketplace and I am having issues with the workflow in the new ADMIN SDK.
With the now deprecated Provisioning API we simply ask for a username and password from the account we are trying to manage.
With the ADMIN SDK it seems as though they would need to go enable the API, create a key and do a lot of manual work for this to happen. This really is a tough option for us as the technical level of our clients is not likely to be able to make this transition.
Is there something like the work flow for the provisioning API where they can enable management from a third party or a recommended workflow for a developer to build an application that can access any number of google apps accounts?
A use case for this is say I want to develop a different option for a console, I want to build a console web app and simply ask for credentials or easy setup routine and allow our users to manage their google apps account in a different way.
Thanks in advance,
Steve
The Admin SDK Directory and Reports APIs work correctly with 2-legged OAuth 1.0a which is what the Google Apps Marketplace currently supports and automates. You do need to turn the Admin SDK on under "Register for additional APIs" from your Vendor Profile page on the marketplace. Also, the Administrative APIs for the domain must be turned on. You'll get a generic error that the domain cannot use the APIs if it's off in which case you can direct the client to the exact CPanel page where they can turn it on.
I have various sites (on their own domain) with their own authentication systems. What I'm trying to do is combine all the authentication into Google's authentication so the users will only have to log in with their Google credentials. What I'm thinking of is that they would log in with their Google credentials and be redirected to a dashboard which has image links to the other sites. The user should be able to go to any of the sites and be automatically logged in since they were already authenticated. I saw that there's an authentication for Google Apps but is this the same thing for my websites?
What I'm not sure about is how does this happen cross domain? How do the other domains know that the user is already authenticated?
Also, if the user logs out, they should not be able to access any of the sites anymore.
Anyone have any experience implementing something like this? Any resources are much appreciated. I will be implementing this in Coldfusion so Coldfusion resources are a bonus.
Your talking about using Google to login/signup i.e. Using OAuth 2.0.
You will need to register each of your app domains with Google. The user will need to confirm each application to allow access (in your case for signup/login).
Resource on Google Login with ColdFusion by Raymond Camden
The point is you need to establish a certain protocol to build a trust.
Other options are:
Google oauth javascript cross domain
My company will be soon switching to Google Apps, and I would like to propose the idea of having our site administration page being authenticated with OpenID. Therefore, any user who is logged into Google Apps would be automatically logged in to our site Administration. Currently, our site administration has it's own list of users and passwords in the DB, but I would like to have the user list based off Google Apps, with their unique identifier saved in our DB. That way, new employees would only have to be set up in Google Apps to access our site Administration.
I've done some research, and come across terms like SSO, OpenID, and SAML, but I can't quite narrow down which route I'm supposed to go. It seems like Google has a lot of paths open for development, and I'm not sure which one I'm supposed to take.
My question is: What kind of Authentication am I seeking for my purpose described above, and can anyone point me in the direction of where to get started? My site is published in ColdFusion 9, so answers specific to that platform are a bonus.
If you just need Web SSO -- I believe you would use your GApps domain as an OpenID Provider. Your application would then act as an RP and consume identities as established by your own GApps domain and company administration. GApps can only act as a SAML Service Provider -- so using SAML for this use case isn't realistic.
HTH
Ian