使用Google会话和帐户选择器的移动应用浏览器的行为 [英] Behaviour of mobile app browsers with Google sessions and Account Chooser
问题描述
我们有：我们有一个离子移动应用程序。与使用Google登录使用OAuth 2.0身份验证。我们有多个适用于OAuth2和SAML的内部应用程序，因此，我们为GSuite启用了SSO，以便所有应用程序都可以无缝地使用一个登录名和密码。现在，当我们点击使用Google登录按钮时，
-
在浏览器应用程序中打开到SSO登录页面。我们启用了SSO
，因此我们设置了login_hint，这有助于我们直接将我们转到
SSO登录页面。 用户输入useremail和密码，并且使用OAuth 2代码参数成功验证后，它重定向到 -
redirect_uri以一种方式完成，当url被触发时，
会使用OAuth 2代码参数重新定向到我们的android应用程序，
然后我们从token和
userinfo endpoints中提取access_token和useremail。
-
根据授权，仪表板显示我们内部的链接
应用程序。可与Google SAML 2.0或OAuth2身份验证配合使用。 p> - 我们尝试访问SAML / OAuth应用，当在Chrome浏览器中设置了一个配置文件时，它会显示帐户选择器，该配置文件列出了所有在设备中同步的帐户，但没有一个用户使用#b登录。它应该显示该帐户或直接登录并显示登录页面。当我们没有设置chrome配置文件时，它不会发生。
- 所有浏览器中的会话会在我们执行以下操作后自动终止并因此再次请求凭证。
- 关闭浏览器选项卡（有时）。
- 从最近的应用程序托盘清除浏览器（大部分时间）
-
$ b -
想知道如何以及何时在谷歌浏览器中自动创建和使用手机杀死会话？
- 关闭浏览器选项卡（有时）。
- 输入您为应用程序注册的OAuth客户端ID。客户ID通常是一串字母和数字，后跟
.apps.googleusercontent.com。 - 在API范围字段中，输入以下字符串：
Opens to SSO login page in a browser app. We have SSO enabled hence we have set login_hint, which helps us in directly takes us to SSO login page.
User inputs useremail and password and it redirects to the redirect_uri post successful authentication with OAuth 2 code param.
The redirect_uri is done in a way that when the url is triggered, it redirect back to our android app again with OAuth 2 code param and then we extract the access_token and useremail from token and userinfo endpoints.
Basis the authorisation, dashboard shows the links to our internal apps. that works with Google SAML 2.0 or OAuth2 authentication.
- When we try to access the SAML/OAuth apps, it shows up the account chooser when there is a profile set in Chrome browser which lists all the accounts synced in device but not the one user have logged in with #b. It should show that account or directly login and show the landing page. Its not happening when we don't have a chrome profile set.
- The sessions in all the browser are killed automatically when we do following and hence asks for the credentials again.
- close the browser tab(sometimes).
- clear the browser from recent apps tray(most of the times)
- restart the device(always)
- You're signed in to Chrome and are syncing passwords
- You're using Smart Lock for Passwords on Android
- Open the G Suite Admin Console.
- Click the Security icon, then click Show More > Advanced Settings > Manage API client access.
- Enter the OAuth client ID you registered for the application. A client ID is normally a string of letters and numbers followed by .apps.googleusercontent.com.
- In the API Scopes field, type the following string: https://www.googleapis.com/auth/plus.me,https://www.googleapis.com/auth/userinfo.email
- If your app needs to request additional scopes to access Google APIs, specify them here.
- Click Authorize. The whitelisting will take effect in about 30 minutes.
- Set up the selected application as a SAML service provider (SP).
- Set up G Suite as a SAML identity provider (IdP).
- Enter application-specific service provider details in Google Admin console.
- Turn on single sign-on (SSO) for the application.
- Verify that the SSO is working.
- On for everyone to turn on the service for all users (click again to confirm).
- Off to turn off the service for all users (click again to confirm).
- On for some organisations to change the setting only for some users.
redirect_uri。
当用户点击移动应用程序中的任何SAML / OAuth 2链接时。仪表板，我们在浏览器应用程序中打开该链接。它应该会自动登录到该应用程序。并带我们前往着陆页，因为我们已经在步骤#a中设置了Google会话。
与预期不符： 有没有在哪里保持会话完好？ 更新 能够发现奇怪的观察结果： 所以问题在于我们设计的SSO。无法找出我们发布到Google的ACS URL的SAML XML中设置的内容。 想知道如何以及何时在Google Chrome手机中自动创建和销毁会话 我认为Google Chrome在手机中的行为与手机中的行为方式相同计算机，因此使用
$ b
|是否有任何方法可以通过账户选择器来显示账户与手机同步的账户？
我们保持SSO关闭，以便Google登录屏幕进入画面。这一切都工作正常。即使重新启动浏览器或手机，会话也不会被中止，而与Android或iOS无关。
以下是使用Google $时要执行的步骤清单b $ b使用工作帐户登录自定义开发的IT应用程序。如果您正在开发移动应用
，请参阅最佳做法
$ b p如果您的应用程序知道该帐户的Google for Work域，则
应将该域传递给auth服务器所以只有在
域中的帐户才会在登录过程中显示。在Android上，这是通过
setHostedDomain
builder方法，在iOS上，这是通过
hostedDomain 属性。
使用
hd参数和REST端点以及
hosted_domain参数JavaScript API。
5。什么...在SAML XML中设置，我们发布到Google的ACS URL。
SAML元数据用于共享
身份提供商（IdP）和服务提供商（SP）之间的配置信息。元数据
IdP和SP都是在XML文件中定义的：
IdP元数据XML文件包含IdP证书，实体ID
重定向网址和帖子网址，例如
saml_idp_metadata.xml 。
<？xml version =1.0encoding =UTF-8？>
< md：EntityDescriptor xmlns：md =urn：oasis：names：tc：SAML：2.0：metadataxmlns：ds =http://www.w3.org/2000/09/xmldsig# entityID =https://test.my.company.comvalidUntil =2024-08-13T07：37：40.675Z>
< md：IDPSSODescriptor WantAuthnRequestsSigned =falseprotocolSupportEnumeration =urn：oasis：names：tc：SAML：2.0：protocol>
< md：KeyDescriptor use =signing>
< ds：X509Certificate> encoded_certificate< / ds：X509Certificate>
< / ds：X509Data>
< / ds：KeyInfo>
< / md：KeyDescriptor>
< md：NameID格式> urn：oasis：names：tc：SAML：1.1：nameid-format：unspecified< / md：NameIDFormat>
< md：SingleSignOnService Binding =urn：oasis：names：tc：SAML：2.0：bindings：HTTP-POSTLocation =https：// https：//test.my.company.com/idp /端点/ HttpPost/>
< md：SingleSignOnService Binding =urn：oasis：names：tc：SAML：2.0：bindings：HTTP-RedirectLocation =https://test.my.company.com/idp/endpoint/HttpRedirect />
< / md：IDPSSODescriptor>
< / md：EntityDescriptor>
SP元数据XML文件包含SP证书，实体ID，
和Assertion Consumer Service URL（ACS URL），例如
saml_sp_metadata.xml 。
< EntityDescriptor xmlns：md =urn：oasis：names：tc：SAML：2.0：metadataentityID =http://client.mydomain.com:80/webconsole>
< SPSSODescriptor WantAssertionsSigned =trueprotocolSupportEnumeration =urn：oasis：names：tc：SAML：2.0：protocol>
< AssertionConsumerService绑定=urn：oasis：names：tc：SAML：2.0：bindings：HTTP-POSTLocation =http://client.mydomain.com:80/webconsole/samlAcsCallback.doisDefault = 真/>
< KeyDescriptor>
< ds：X509Certificate> encoded_certificate< / ds：X509Certificate>
< / ds：X509Data>
< / ds：KeyInfo>
< / KeyDescriptor>
< NameIDFormat> urn：oasis：names：tc：SAML：2.0：nameid-format：entity< / NameIDFormat>
< / SPSSODescriptor>
< / EntityDescriptor>
在使用SAML登录到Web控制台之前，必须上传IdP
，并且必须生成来自SP的元数据。生成
SP元数据后，它必须与IdP共享。请联系
IdP获取共享SP元数据的说明。
使用SAML
协议创建一个身份提供商（IdP）元数据XML文件。有关SAML元数据规范，请转至 Oasis
网站， OASIS元数据
安全声明标记语言（SAML） ）
V2.0 。
创建密钥库文件。有关密钥库文件的信息，请参阅
为SAML
集成创建证书。
有关keytool实用程序的更多信息，请转至 Oracle
文档网站， keytool - 密钥和
证书管理
工具。
要将G Suite设置为SAML身份提供商（IdP），您需要输入
SAML服务提供商的每个URL个人
预先配置的云应用程序您计划设置。
链接为每个预配置的云
应用的实体
ID，ACS URL和启动URL值。
6。对单一登录（SSO）进行故障排除
本文档
提供了解决在
集成期间遇到的常见错误消息或使用使用G Suite的基于SAML的单一登录
（SSO）服务提供商（SP）。
Problem : Trying to create SSO between mobile app. and browser.
What we have:
We have an ionic mobile app. with "Login with Google" using OAuth 2.0 authentication. We have multiple inhouse apps that works on OAuth2 and SAML hence, we have SSO enabled for GSuite so that all apps work seamlessly with one login and password. Now when we hit the "Login with Google" button,
What is expected:
When user hits any of the SAML/OAuth 2 link from mobile app. dashboard, we open that link in browser app. and it should get automatically logged in to that app. and take us to the landing page as we have already Google sessions set in step #a.
Things deviating from expectations:
Wanted to understand how and when the sessions are created and killed automatically in Google Chrome in mobile phones ?
Is there any where to keep the session intact ? |Is there any way to bye-pass the account chooser showing the accounts synced with phone ?
Update
Able to figure out strange observation: We kept SSO off so that Google Login screen comes into picture. With this everything is working fine. Sessions are not killed even if restart browser or phone irrespective of Android or iOS.
So the problem is in SSO that we have designed. Not able to figure out what is to be set in SAML XML that we post to Google's ACS URL.
1. Wanted to understand how and when the sessions are created and killed automatically in Google Chrome in mobile phones?
I think Google Chrome acts in mobile phones the same way that it does in computers, so sessions are created and killed using the HTML5 sessionStorage, user configuration and device policies:
There are two types of Web Storage so far, and these are the localStorage, and the sessionStorage. The main difference is that the localStorage persists over different tabs or windows, and even if we close the browser, accordingly with the domain security policy and user choices about quota limit.
Also, it's important to know how Chrome saves and syncs passwords:
How Chrome saves and syncs passwords (in computer and Android devices) depends on whether you want to store and use them across devices. When synced, passwords can be utilized on Chrome on all your devices, and across some apps on your Android device.
Your passwords are saved to your Google Account if either of the following are true:
Otherwise, your passwords are only stored on Chrome on your computer or Android device.
How Chrome saves and syncs passwords (in iPhone and iPad devices) depends on whether you want to store and use them across devices.
Your passwords are saved to your Google Account if you're signed in to Chrome and are syncing passwords.
Otherwise, your passwords are only stored on Chrome on your iPhone or iPad.
2. Is there any way to keep the session intact ?
I'm not skilled/interested in iOs or HTML5 development, but I tried something similar for Android and a legacy Google Apps domain when Google launched Smart Lock for Passwords on Android:
Programmatically save and retrieve credentials, and automatically sign users in across devices and websites in Chrome.
Note: SSL is required on your server to Enable automatic sign-in across apps and websites
The Smart Lock for Passwords and Connected Accounts API facilitates the saving and retrieval of credentials for your app and associated site
You can Handle multiple saved credentials and manually Delete stored credentials
When user input is required to select a credential, the getStatusCode() method returns RESOLUTION_REQUIRED. In this case, call the status object's startResolutionForResult() method to prompt the user to choose an account. Then, retrieve the user's chosen credentials from the activity's onActivityResult() method by passing Credential.EXTRA_KEY to the getParcelableExtra() method.
And Sign In Using ID Tokens available when a Credential object's user ID matches the user ID of a Google account that is signed in on the device.
How to implement it and useful scenarios to test and check it in related SO answers.
3. Is there any way to bye-pass the account chooser showing the accounts synced with phone ?
Use Google Sign-In with IT Apps
Whitelist the application so that your users will not see a confirmation screen when they sign in. This step, combined with the next steps (point 4: pass Google for Work domain of the account to the auth server, so only accounts in that domain are displayed during sign-in), ensures that users of your IT application can automatically sign in. To whitelist your app:
Note: The whitelisting will not work if the app starts the OAuth/Open ID Connect flow and includes the parameters offline or prompt. These parameters are generally not needed for IT apps.
Force/bypass google account chooser in OAuth2 authorization URLs
The following parameter is supported in OAuth2 authorization URLs: prompt
Currently it can have values '
none', 'select_account', and 'consent'.none: Will cause Google not to show any UI, and therefore fail if the user needs to login, or select an account in case of multi-login, or consent if first approval. It can be run in an invisible i-frame to obtain a token from previously authorised users before you decide, for instance, to render an authorization button.
consent: Will force the approval page to be displayed even if the user has previously authorised your application. May be useful in a few corner cases, for instance, if you lost the refresh_token for the user, as Google only issues refresh_tokens on explicit consent action.
select_account: Will cause the account selector to display, even if there's a single logged-in user, just as you asked.
select_account can be combined with consent, as in:
prompt=select_account+consent
using authorisation via the JS client library
You are not getting the multi-user selection screen because of the following parameter: authuser=0 This automatically selects the first account you are signed in with (authuser=1 would choose the second etc.).
4. Update: With SSO off all is working fine...sessions are not killed...
Here's how to set up Single Sign-On (SSO) via SAML for the Slack® application.
Using Security Assertion Markup Language (SAML), your users can use their Google Cloud credentials to sign in to enterprise-cloud applications.
As an administrator, you have to configure a few things to make it work, including:
Configure the pre-integrated cloud applications or your own SAML app
Sign in. Click Apps > SAML apps. Select the Add a service/App to your domain and setup:
Turn on SSO to your new SAML app:
Sign in to your Admin console. Go to Apps > SAML apps.
Select the app. At the top of the grey box, click More Settings and choose:
Use Google Sign-In with IT Apps
The following is a checklist of steps to take when using Google Sign-In with work accounts for a custom-developed IT application. If you are developing a mobile app, refer to the best practices for mobile as well.
If your app knows the Google for Work domain of the account, you should pass that domain to the auth server so only accounts in that domain are displayed during sign-in. On Android, this is done with the setHostedDomain builder method, and on iOS, this is done with the hostedDomain property.
This is also done using the
hdparameter with the REST endpoint, and the hosted_domain parameter with the JavaScript API.
5. What ... to set in SAML XML that we post to Google's ACS URL.
Configuring Provider Metadata for SAML Integration
SAML metadata is used to share configuration information between the Identity Provider (IdP) and the Service Provider (SP). Metadata for both the IdP and the SP is defined in an XML file:
The IdP metadata XML file contains the IdP certificate, the entity ID, the redirect URL, and the post URL, for example, saml_idp_metadata.xml.
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://test.my.company.com" validUntil="2024-08-13T07:37:40.675Z">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>encoded_certificate</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://https://test.my.company.com/idp/endpoint/HttpPost"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://test.my.company.com/idp/endpoint/HttpRedirect"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
The SP metadata XML file contains the SP certificate, the entity ID, and the Assertion Consumer Service URL (ACS URL), for example, saml_sp_metadata.xml.
<EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://client.mydomain.com:80/webconsole">
<SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://client.mydomain.com:80/webconsole/samlAcsCallback.do" isDefault="true"/>
<KeyDescriptor>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>encoded_certificate</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:entity</NameIDFormat>
</SPSSODescriptor>
</EntityDescriptor>
Before using SAML to log on to the Web Console, metadata from the IdP must be uploaded and metadata from the SP must be generated. After the SP metadata is generated, it must be shared with the IdP. Contact the IdP for instructions on sharing the SP metadata.
Create an Identity Provider (IdP) metadata XML file using the SAML protocol. For SAML metadata specifications, go to the Oasis website, Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0.
Create a keystore file. For information on keystore files, see Creating Certificates for SAML Integration.
For more information on the keytool utility, go to the Oracle Documentation website, keytool - Key and Certificate Management Tool.
To set up G Suite as SAML identity provider (IdP), you need to enter the SAML service provider URLs for each of the individual pre-configured cloud applications you plan to set up.
Links for Entity ID, ACS URL, and Start URL values for each of the pre-configured cloud apps.
6. Troubleshooting Single Sign-On (SSO)
This document provides steps to resolve common error messages encountered during the integration or use of SAML-based Single Sign-On (SSO) with G Suite when Google is the service provider (SP).
这篇关于使用Google会话和帐户选择器的移动应用浏览器的行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
