We have a gmail gadget in apps marketplace that use SSO authorization described on this link: https://developers.google.com/google-apps/marketplace/best_practices?csw=1#gadget_sso. With recent update of marketplace is gadget flow will be updated to OAuth2 or it will stay the same?
If yes, then what is the deadline for the migration? I wasn't able to find this on the documentation about release.
Thank you!
In the new marketplace setup, you still have to use a popup to setup the correlation between the opensocial Id and the google user. But the popup will no longer use OpenId/SSO to identify the user to the application. Instead these two OAUTH2 scopes are pre-authorized :
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
and that's enough to get the identity of the user.
Related
I'm working on a SAML SSO integration for our app using Google / G Suite. Our customers configure our SAML app in their company's G Suite admin settings. The integration works correctly in most cases:
Suppose you're not signed into a Google account yet. You initiate the SSO process. You're prompted to sign into your company Google account, and SSO works correctly.
Suppose you're already signed into your company Google account and your personal Google account. You initiate the SSO process. You see an account chooser. If you choose your company Google account, SSO works correctly.
However, SSO fails in this case:
Suppose you are only signed into your personal Google account. Google does not display the account chooser. Instead, you immediately get a a 403 error: "Error: app_not_configured_for_user."
This has led to a very confusing experience for our users. It's pretty common that you're currently only signed into one google account that's not your company google account. Furthermore, the error page is opaque -- it's not clear to a user what they did wrong.
Is there any way to always show the account chooser? For example, are there any parameters we can add to the /o/saml2/idp url or the SAML AuthnRequest? (E.g. we tried setting ForceAuthn and adding a <saml:Subject> block in the AuthnRequest, but it seems Google's SAML does not support either.)
Or is there a way for our app to get a callback on error, so we can show a more meaningful error message?
(I contacted G Suite support, and they said to ask our question on Stack Overflow instead. Appreciate your help here!)
Instead of redirecting to directly from your app to the Google IDP, you need to redirect to
https://accounts.google.com/accountchooser?continue={theredirectURL}
See
Google SAML app_not_configured_for_user / equivalent of prompt=select_account SAML
if you using a passport-saml
There is a fork that fixes this behavior.
Set in configuration googleAuth: true and then during authorization there will be a redirect to the google account selection page
I had this same issue. When I then added the G suite account to my Android device under Settings > Accounts and retried the login flow, I was properly prompted with the Account Chooser. Not the solution I was really looking for, but it did change the outcome.
I had the exact same problem when working with Keeper Password Manager. I solved it by erasing everything from ~/Library/Application Support/Keeper Password Manager/Cookies
I suggest you look for a similar folder in your app and do the same
I have a bot running on a hosting page where users are logged in using SSO.
I want to authenticate the user in the bot automatically when the bot starts and I do not want to use anAuthCard to do it. Just want to automatically authenticate the user without prompting anything to him, just using SSO.
I found an article that refers three ways to authenticate an user in the bot:
Sharing the client's user token directly with the bot via ChannelData
Using an OAuthCard to drive a sign-in experience to any OAuth provider
A third option, called Single Sign-On (SSO), that is in development.
And, according to the article my situation is:
WebChat in an authenticated website where the user is already signed in and the website has a token to the same identity provider but to a different app that the bot needs -> in the future, this is single sign-on, but for now you 'll need to use an OAuthCard.
Is there any update about this functionality? How can I authenticate the user into the bot without using an OAuthCard or a SigninCard?
Thanks in advance
Not sure if you have tried the option of using WebChat with Azure Bot Service’s Authentication which provides built-in authentication capability to authenticate chat users with various identity providers such AAD, GitHub, Facebook, etc.
If you are looking for this built-in feature, then probably you need to build your own custom built solution using Google sign-in by passing the token ID of the authenticated users. Or for an Account linking OAuth2 solution as explained in this link: How to implement Login in Dialogflow chatbot.
Microsoft guys Are looking at the issue now. you can track the progress here.
I implemented a solution that worked for me. I have the bot running in a .net core web app
Here's what I did:
Generate an userId before initializing the BotApp
When the user clicks on the button to open the webchat, I'm opening an authenticated controller in a popup that receives the generated userId. The page is authenticated, so you will need to authenticate. I store the userId in my DB, along with access_token and some user information. The controller should be created in the same webapp where the bot is running.
After storing all the information I close the tab and start the BotApp with the generated userId
In bot code you will be able to query your DB (using userId).
To wait until the popup close, you can have a look into this here.
I hope that this helps someone.
Best regards
How can I programmatically retrieve information about an OAuth client given its appId (xxxx.apps.googleusercontent.com). I am interested in retrieving Google API scopes the app is requesting (e.g.: https://www.googleapis.com/auth/userinfo.email) along with marketplace ratings and user coun t (if applicable).
Screenshot
I believe you can only access those stats if you own the app/add-on. Assuming that you're working on a GSute add-on, if you deploy the app via GSuite Marketplace you'll have to explicitly specify the scopes your app requires and you can check those scopes from your Google Console. I believe that there is also a dashboard available to the app developer (probable from Google Console) with analytic data related to performance.
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.
We publish an app that use OAuth 2.0 API access on Google Apps Marketplace. It got reviewed by Google and they said our app is invalid because it shows permission screen when a user first runs the app. (The app will be removed from the Google Apps Marketplace if our app is not fixed within 30 days) To solve this issue, we have some problems.
Our app uses OpenID Connect to make users login.
Our app also uses Spreadsheet API and Calendar Resource API (OAuth 2.0 Web Application Flow)
So our questions related above is the followings:
1.
Although our app uses OpenID Connect for login, using OpenID Connect forces our app to show the permission screen. Doesn't it meet the best practice below of Google Apps Marketplace?
https://developers.google.com/apps-marketplace/practices#5_use_one-click_single_sign-on
We followed the OpenID Connect document provided by Google:
https://developers.google.com/accounts/docs/OAuth2Login
2.
Since Spreadsheet API and Calendar Resource API don't currently support the authentication method using Service Account with OAuth 2.0, we chose to use the method of Web Application Flow. Our app get the token when users login, but Google said to us that it fails to meet their SSO requirements. To solve the issue, we are thinking to change our app to authorize AFTER login within the app instead (use Web Application Flow method as it is). Does the way meet the SSO requirements? In other words, is it OK to show permission screen if after login?
We will applicate if anyone can tell us good solution to solve these problems.
Thanks,
If you register your scopes in the Google Apps Marketplace configuration screen, and then only request those scopes in the OpenID Connect flow, then the permissions screen should be automatically skipped. Please ensure the scopes match between these two locations.