android - 具有 Google session 和帐户选择器的移动应用浏览器的行为

Question

问题:尝试在移动应用程序之间创建 SSO。和浏览器。

我们拥有什么:

我们有一个 ionic 移动应用程序。使用 OAuth 2.0 身份验证“通过 Google 登录”。我们有多个适用于 OAuth2 和 SAML 的内部应用程序，因此，我们为 GSuite 启用了 SSO，以便所有应用程序只需一个登录名和密码即可无缝工作。现在，当我们点击“使用 Google 登录”按钮时，

1. 在浏览器应用中打开 SSO 登录页面。我们已启用 SSO因此我们设置了login_hint，它可以帮助我们直接进入SSO 登录页面。

2. 用户输入用户邮箱和密码，然后重定向到redirect_uri 使用 OAuth 2 代码参数成功进行身份验证。

3. redirect_uri 的实现方式是当 url 被触发时，它使用 OAuth 2 代码参数再次重定向回我们的 Android 应用程序，然后我们从 token 中提取 access_token 和 userremail用户信息端点。

4. 根据授权，仪表板显示我们内部的链接应用。适用于 Google SAML 2.0 或 OAuth2 身份验证。

预期结果:

当用户点击移动应用程序中的任何 SAML/OAuth 2 链接时。仪表板，我们在浏览器应用程序中打开该链接。它应该会自动登录到该应用程序。并带我们进入登陆页面，因为我们已经在步骤 #a 中设置了 Google session 。

事情偏离预期:

• 当我们尝试访问 SAML/OAuth 应用时，如果 Chrome 浏览器中设置了一个配置文件，其中列出了设备中同步的所有帐户，但不列出使用 #b 登录的一个用户，它就会显示帐户选择器。它应该显示该帐户或直接登录并显示登陆页面。当我们没有设置 chrome 配置文件时，这种情况就不会发生。
• 当我们执行以下操作时，所有浏览器中的 session 都会自动终止，因此再次要求提供凭据。
  • 关闭浏览器选项卡(有时)。
  • 从最近使用的应用程序托盘中清除浏览器(大多数时候)
  • 重新启动设备(始终)

想要了解手机中的 Google Chrome 中如何以及何时自动创建和终止 session ？

有什么地方可以保持 session 完整吗？|有什么方法可以绕过显示与手机同步的帐户的帐户选择器吗？

更新

能够找出奇怪的观察结果:我们关闭了 SSO，以便显示 Google 登录屏幕。有了这个，一切都工作正常。无论 Android 还是 iOS，即使重新启动浏览器或手机， session 也不会被终止。

所以问题出在我们设计的 SSO 上。无法弄清楚我们发布到 Google ACS URL 的 SAML XML 中要设置什么。

Answer 1

1。想要了解手机中的 Google Chrome session 如何以及何时自动创建和终止？

我认为 Google Chrome 在手机中的运行方式与在计算机中的运行方式相同，因此使用 HTML5 sessionStorage 创建和终止 session 。 ，用户configuration和设备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.

此外，了解 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:

• You're signed in to Chrome and are syncing passwords
• You're using Smart Lock for Passwords on Android

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.有什么办法可以保持 session 完整吗？

我对 iO 或 HTML5 开发不熟练/不感兴趣，但当 Google 推出 Smart Lock for Passwords on Android 时，我对 Android 和旧版 Google Apps 域尝试了类似的操作。 :

Programmatically save and retrieve credentials, and automatically sign users in across devices and websites in Chrome.

注意:您的服务器上需要 SSL 才能 Enable automatic sign-in across apps and websites

密码智能锁和 Connected Accounts API方便保存和检索您的应用程序和关联网站的凭据

您可以Handle multiple saved credentials和 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.

和Sign In Using ID Tokens当 Credential 对象的用户 ID 与设备上登录的 Google 帐户的用户 ID 匹配时可用。

如何implement it和有用的场景test和 check它在相关的SO答案中。

<小时/>

3.有没有办法绕过显示与手机同步的帐户的帐户选择器？

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:

• 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.

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。更新:关闭 SSO 后一切正常... session 不会被终止...

SAML-based Federated SSO

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:

• 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.

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:

• 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.

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 hd parameter with the REST endpoint, and the hosted_domain parameter with the JavaScript API.

<小时/>

5。在我们发布到 Google ACS URL 的 SAML XML 中设置什么内容。

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.

SAML service provider URLs

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。单点登录 (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).