I am considering developing an application for the Apps for Business Marketplace. I see that new rules takes affect on November 19th. Referring to the new documentation (https://developers.google.com/apps-marketplace/) I do not see that any SSO requirement exists. There is allot of talk about migrating to new sign on methods, but I see no mention of sign on requirements.
What are the sign on requirements as of November 19th?
If SSO continues to be required or if I publish before Nov. 19th, my application requires security token from my API, in order to carry out API exchanges. To get this token a user/pass exchange is required one time. They would never need to enter a user/pass for my app after that. Will a one time exchange for the security token be denied under a SSO requirement?
For example the statement regarding SSO that an app cannot do is:
The end user should not be required to enter a username and password when invoking an application from within Google Apps. (https://developers.google.com/google-apps/marketplace/sso)
In my case it would not be required for the user to enter every time, just on the initial creation of the account. After that I would retain the token from my site, encrypted with the Installed App.
Would my app be denied for requiring this one time exchange under the SSO policy?
Mark
You will have to use SSO (or should if at all possible) -- see this part of the documentation: Besides, that is a better practice and should make your users feel more trust for your application.
From what I gather (note that I'm building my first marketplace app) you should not prompt users to enter username/password on your site. I am creating user record & storing token behind the scenes. So the user sees Google authorization screen, agrees to let my app use some data, accepts and sign-in right away without any prompt to create an account. After this, user will not be prompted in the future because I have their google id linked to a user record.
From their site - https://developers.google.com/google-apps/marketplace/sso#user_experience
As long as you don't have any intermediate screen, your app should be approved.
Related
I have a web app which sends emails (gmail) in name of my users
When a user registers, she supplies gmail account and password. Also she has to enable access for Less Secure Apps (I recommend to create a new account for this)
Then I can open a gmail session
session = Session.getInstance(props, new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user.getEmail(), user.getPassword());
}
});
and send emails on her behalf.
Unfortunately this is going to stop working next 30th May, when Google will allow only OAUTH2 access
I have followed Java Quickstart for Gmail API and I have code up and running for sending emails with OAUTH2: enable gmail api, create an application on google cloud platform, grant send permission, oauth2 client id credential created...
The problem I have is I can't see a way to automatize this task because when creating an authorized credential, a consent screen displays on browser and you have to select the account to be granted manually (maybe because my app in google cloud platform is still pending to be reviewed)
Is there a way to infer the gmail account you want to access from the credentials file (client_secret.json)? Is there a way to automatize this?
No, or yes. It depends.
The whole point of OAuth2 is to improve security by working with authorization tokens rather than asking for user credentials. To do this the user has to consent to the app's access request, and thus the OAuth consent screen cannot be bypassed. This is
explained in Google's documentation. It's not related to your app's review status but rather it's the way OAuth works.
You can still work in a similar way, though . Instead of asking for username and password upon the user's registration you can redirect them to the OAuth consent screen so they can authorize your app. Make sure that your app is requesting offline access type and then you can retrieve an access_token and a refresh_token. These will essentially work as your credentials and you can use the refresh token to generate new access tokens when needed without having the user go through the consent screen each time.
The refresh token doesn't have a "natural" expiration so you can keep using it indefinitely, but there are a few scenarios where it will become invalid, such as it not being used for six months, the user changing passwords (if using Gmail scopes), the user manually revoking access, etc. In these cases you will need to direct them to the consent screen again to reauthorize your app.
In this sense, your app can still work automatically without user input except the initial setup, which you already had to deal with when they supplied you with their credentials. The refresh token expiration can even be compared to what you had to do when the users changed their passwords in your current workflow.
One exception to this are service accounts. If you and your users are part of a Google Workspace domain you can delegate domain-wide access to it, then the service account will be able to access user data without any manual input. Of course, this is because as the domain administrator you pretty much own all the accounts under it. But if you're working with a publicly available application you will have to deal with the limitations I mentioned above.
Sources:
Google's auth overview
Using OAuth 2.0 to access Google APIs
OAuth 2.0 for web applications
The OAuth consent screen
I received this error when trying to authorize my app with my own account:
Your project is trying to access scopes that need to go through the verification process.
{invalid=https://www.googleapis.com/auth/contacts}
If you need to use one of these scopes, submit a verification request. Learn More
When I use a different account, the error message is different:
This app hasn’t been verified to access:
{invalid=https://www.googleapis.com/auth/contacts}
Are you the developer? If this project needs these scopes, sign in to an account with access to edit your project and try again.
If not, contact the developer for help.
As per the announcement on May 11, 2017, publicly available applications with access to certain user data must pass review. If you see an access error for your app, submit a request using our OAuth Developer Verification form.
For personal-use apps and those you are testing, join the Google group Risky Access Permissions By Unreviewed Apps, which allows you to approve data access for personal and testing accounts. See the Google API Services User Data Policy for more information.
UPDATE: Corrected broken link to form.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.
I made a members-only site that uses Google oauth2 to authorise users. The site is built with the Laravel framework and Artdarek's oath library.
When the authorization callback comes from Google, I lookup the user record in the DB by email and proceed to the protected page if the record exists, otherwise to a register page.
The problem is some of our members use two Google accounts. One user registered via his primary account (e.ge. a#gmail.com). The next day he returned and mistakenly tried to login with b#gmail.com. Naturally the system showed him the registration page. From that time on each time he visits the site the authentication mechanism sees him using his second (unwanted) set of credentials.
To resolve this one case I instructed him to logout of all accounts (on both sides), clear cookies and start from scratch but this is not a practical solution for all users. In same cases even this measure does not seem to correct the problem.
How can I solve this case? What is the right way to request oauth authentication and get them back from the right account? Can I force Google to ask the user with which account to proceed?
Google will automatically ask the user which account they want on an oauth request if they enable the account chooser.
I have logged into my Google Apps and my Google account, so for me on an oauth request, I get the following prompt:
In order to do the same for your user, they have to click "Stay signed in", but of course this is not advisable for public computers.
Beyond the above, I'm afraid not much can be done. - if they logged in with a#gmail.com at that time, these are the credentials you will receive.
They way I solve this problem is to have a field where the customer can add additional emails, and select one that is primary. I will then inspect against these emails when a request comes in to avoid duplicate user accounts.
I’m new with the marketplace and I’m developing an application to replace google's login with my app, which uses strong authentication.
To use it you don’t need to install anything, it’s only a matter of configuration of your google app. When you try to access mail.google.com/a/yourdomain.com it will redirect to our application where the validation process occurs, and after validating it will return to google web site.
Same happens with logout and password change, you will be redirected to my app.
When a user needs to change the account password, we use google admin api to change it, of course, it requieres a previous authorization from a domain user with administration privileges.
Question is, how to publish an application like this on the market place?, I don’t see how to do it according to the new regulations from november 19th, for example, the application type and the fact that it should be an installable listing.
Someone who can give me a hint or example.
Thanks in advance.
Fernando.
--- EDITED --- to answer to Koma
The thing is, we already have the application, what we're doing now is to do some changes to make it ready to use it with google apps.
There’s an option in the security section called “set up single sign-on (SSO)” where you configure 3 URL’s for:
Sign-in page URL (URL for signing in to your system and Google Apps)
Sign-out page URL (URL to redirect users to when they sign out)
Change password URL (URL to let users change their password in your system; when defined here, this URL is shown even when Single Sign-on is not enabled)
When you a user needs to change your account’s password you will be redirected to our application (because google have delegated that responsibility to Us). There, through OAUTH and Google Admin API, we will change the password for your google user.
We want to be listed in google’s marketplace as a solution for strong authentication delegating that functionality to our application, but we don’t see how because the user that will use our solution doesn’t need to install anything, and according to what I understand we are forced to upload something to be listed
Does that make sense to you?
From what I read, you want to replace authentication with your own. That's not feasible with a market place app.
You need to implement a SAML identity provider
https://developers.google.com/google-apps/sso/saml_reference_implementation