Поведение браузеров мобильных приложений с сеансами Google и выбор учетной записи

Проблема: попытка создания единого входа между мобильным приложением. и браузера.

Что мы имеем:

У нас есть ионное мобильное приложение. с "Войти в Google" с использованием аутентификации OAuth 2.0. У нас есть несколько встроенных приложений, которые работают на OAuth2 и SAML, поэтому у нас есть SSO для GSuite, так что все приложения работают с одним логином и паролем. Теперь, когда мы нажмем кнопку "Войти с Google",

Открывается страница входа в систему SSO в приложении для браузера. У нас включен SSO поэтому мы установили login_hint, который помогает нам в прямом Страница входа в систему SSO.
Пользователь вводит пароль пользователя и пароль и перенаправляет его на redirect_uri отправляет успешную аутентификацию с параметром кода OAuth 2.
Redirect_uri выполняется таким образом, что когда URL-адрес запускается, он перенаправляет обратно в наше приложение для Android снова с параметром кода OAuth 2 и то мы извлекаем access_token и useremail из токена и конечные точки userinfo.
Основываясь на авторизации, на панели мониторинга отображаются ссылки на наши внутренние Программы. который работает с аутентификацией Google SAML 2.0 или OAuth2.

Ожидается:

Когда пользователь нажимает на любую из ссылок SAML/OAuth 2 из мобильного приложения. панель инструментов, мы открываем эту ссылку в приложении для браузера. и он должен автоматически войти в это приложение. и забираем нас на целевую страницу, поскольку у нас уже установлены сеансы Google, установленные в шаге #a.

Вещи, отклоняющиеся от ожиданий:

Когда мы пытаемся получить доступ к приложениям SAML/OAuth, он отображает выбор учетной записи, когда в браузере Chrome есть профиль, в котором перечислены все учетные записи, синхронизированные на устройстве, но не один пользователь вошел в систему С#b. Он должен показывать эту учетную запись или напрямую войти и показать целевую страницу. Его не происходит, когда у нас нет набора хромовых профилей.
Сессии во всех браузерах автоматически уничтожаются, когда мы это делаем, и, следовательно, снова запрашиваем учетные данные.
- закрыть вкладку браузера (иногда).
- очистить браузер от последнего лотка приложений (в большинстве случаев)
- перезагрузите устройство (всегда)

Хотелось понять, как и когда сеансы создаются и автоматически убиваются в Google Chrome на мобильных телефонах?

Есть ли там, где сохранить сеанс в целости? | Есть ли способ пропустить учетную запись, отображающую учетные записи, синхронизированные с телефоном?

Обновление

Возможность выяснить странное наблюдение: Мы сохранили SSO, чтобы на экране Google Google появился экран. С этим все работает нормально. Сеансы не убиваются даже при перезапуске браузера или телефона независимо от Android или iOS.

Итак, проблема в SSO, которую мы разработали. Не удалось определить, что должно быть установлено в XML SAML, который мы отправляем в URL-адрес Google ACS.

Ответ 1

1. Хотелось понять, как и когда сеансы создаются и автоматически убиваются в Google Chrome на мобильных телефонах?

Я думаю, что Google Chrome действует на мобильных телефонах так же, как на компьютерах, поэтому сеансы создаются и уничтожаются с помощью HTML5 sessionStorage, пользователь конфигурация и устройство политики:

До сих пор существует два типа Web Storage, и это localStorage и sessionStorage. Основное различие заключается в том, что localStorage сохраняется на разных вкладках или окнах, и даже если мы закрыть браузер, соответственно с политикой безопасности домена и выбор пользователя о пределе квоты.

Также важно знать как Chrome сохраняет и синхронизирует пароли:

Как Chrome сохраняет и синхронизирует пароли (на компьютерах и устройствах Android) зависит от того, хотите ли вы хранить и использовать их через устройства. При синхронизации пароли могут Chrome на всех ваших устройствах и в некоторых приложениях на вашем Android-устройстве устройство.

Ваши пароли будут сохранены в вашей учетной записи Google, если любой из следующие верно:

Вы вошли в Chrome и синхронизируете пароли.

Вы используете Smart Lock для паролей на Android
В противном случае ваши пароли сохраняются только в Chrome на вашем компьютере или устройстве Android.

Как Chrome сохраняет и синхронизирует пароли (в устройствах iPhone и iPad) зависит от того, хотите ли вы хранить и использовать их на разных устройствах.

Ваши пароли будут сохранены в вашей учетной записи Google, если вы вошли в систему Chrome и синхронизирует пароли.

В противном случае ваши пароли будут храниться только в Chrome на вашем iPhone или IPAD.

2. Есть ли способ сохранить целостность сеанса?

Я не умею/заинтересован в разработке iOS или HTML5, но я попробовал нечто подобное для Android и унаследованного домена Google Apps, когда Google запустил Smart Lock для паролей на Android:

Программно сохранять и извлекать учетные данные и автоматически подписывать пользователей на всех устройствах и веб-сайтах в Chrome.

Примечание. На вашем сервере требуется SSL Включить автоматическую регистрацию через приложения и веб-сайты p >

Умный замок для паролей и Connected Accounts API облегчает сохранение и извлечение учетных данных для вашего приложения и связанного с ним сайта

Вы можете Обработать несколько сохраненных учетных данных и вручную Удалить сохраненные учетные данные

Когда пользовательский ввод требуется для выбора учетных данных, Метод getStatusCode() возвращает RESOLUTION_REQUIRED. В этом случае позвоните метод startOrsolutionForResult() объекта состояния для запроса пользователю выбрать учетную запись. Затем выберите пользователя учетные данные из действия onActivityResult() путем передачи Credential.EXTRA_KEY для метода getParcelableExtra().

И Войдите, используя идентификаторы токенов, если идентификатор пользователя объекта учетных данных совпадает с идентификатором пользователя учетной записи Google, которая была подписана на устройство.

Как реализовать его и полезные сценарии test и проверьте его в связанных ответах SO.

3. Есть ли способ обойти учетную запись, отображающую учетные записи, синхронизированные с телефоном?

Использовать вход в Google с помощью ИТ-приложений

Перейдите в белый список приложения, чтобы ваши пользователи не увидели экран подтверждения при входе в систему. Этот шаг в сочетании с следующие шаги (пункт 4: передача домена Google for Work учетной записи на сервер auth, поэтому во время входа в систему отображаются только учетные записи в этом домене), гарантирует, что пользователи вашего ИТ-приложения могут автоматически войдите. Для белого списка вашего приложения:

Откройте консоль консоли G Suite.

Нажмите значок "Безопасность", затем нажмите "Показать больше" > "Дополнительные параметры" > "Управление доступом к клиенту API".

Введите идентификатор клиента OAuth, который вы зарегистрировали для приложения. Идентификатор клиента обычно представляет собой строку букв и цифр, за которыми следует .apps.googleusercontent.com.

В поле API Scopes введите следующую строку: https://www.googleapis.com/auth/plus.me,https://www.googleapis.com/auth/userinfo.email

Если вашему приложению требуется запросить дополнительные области для доступа к API Google, укажите их здесь.

Нажмите "Авторизовать". Белый список вступит в силу примерно через 30 минут.
Примечание. Белый список не будет работать, если приложение запускает поток OAuth/Open ID Connect и включает в себя параметры офлайн или <Сильного > строка. Эти параметры обычно не нужны для ИТ-приложений.

Принудительное/обходное определение учетной записи google в URL-адресах авторизации OAuth2

В URL-адресах авторизации OAuth2 поддерживается следующий параметр: prompt

В настоящее время он может иметь значения "none", "select_account" и "consent".

none: приведет к тому, что Google не будет показывать какой-либо пользовательский интерфейс и, следовательно, сбой, если пользователь необходимо войти в систему или выбрать учетную запись в случае множественного входа или согласие если первый одобрение. Его можно запустить в невидимом i-кадре, чтобы получить токен от ранее авторизованных пользователей до того, как вы решите, для экземпляр, чтобы сделать кнопку авторизации.

согласие: принудительно отобразит страницу утверждения, даже если пользователь ранее разрешил ваше выражение. Может быть полезно в нескольких например, если вы потеряли refresh_token для пользователя, поскольку Google только выдает refresh_tokens на явное действие согласия.

select_account: приведет к отображению селектора учетных записей, даже если есть один зарегистрированный пользователь, точно так же, как вы просили.

select_account можно комбинировать с соглашением, как в: prompt=select_account+consent

используя авторизацию через клиентскую библиотеку JS

Вы не получаете экран выбора нескольких пользователей из-за следующий параметр: authuser = 0 Это автоматически выбирает первый счет, с которым вы вошли в систему (authuser = 1 выбирает второй и др.).

4. Обновление: при SSO все работает нормально... сеансы не убиты...

федеративный SSO на основе SAML

Здесь, как настроить Single Sign-On (SSO) через SAML для приложения Slack®.

Используя язык разметки безопасности (SAML), ваши пользователи могут использовать их учетные данные Google Cloud для входа в корпоративное облако приложения.

Как администратор, вам нужно настроить несколько вещей, чтобы заставить его работать, в том числе:

Настроить выбранное приложение как поставщика услуг SAML (SP).

Настройка G Suite как поставщика удостоверений SAML (IdP).

Введите сведения о поставщике конкретного приложения в консоли администратора Google.

Включить единый вход (SSO) для приложения.

Убедитесь, что SSO работает.

Настроить предварительно интегрированные облачные приложения или собственное приложение SAML

Войти. Нажмите Приложения > Приложения SAML. Выбрать Добавить службу/Приложение в свой домен и настроить:

Включить SSO в новое приложение SAML:

Войдите в свою консоль администратора. Идти к Приложения > Приложения SAML.

Выберите приложение. В верхней части серого окна нажмите "Дополнительные настройки" и выбрать:

Включение всех для включения службы для всех пользователей (нажмите еще раз, чтобы подтвердить).

Выключить, чтобы отключить услугу для всех пользователей (нажмите еще раз, чтобы подтвердить).

Включение некоторых организаций для изменения настроек только для некоторых пользователей.

Использовать вход в Google с помощью ИТ-приложений

Ниже приведен список действий, которые необходимо предпринять при использовании Google. Вход с рабочими учетными записями для специализированного ИТ-приложения. Если вы разрабатываете мобильное приложение, см. лучшие практики для мобильный.

Если ваше приложение знает домен Google for Work учетной записи, вы должен передать этот домен серверу auth, поэтому только учетные записи в этом домен отображаются во время входа в систему. В Android это делается с помощью setHostedDomainметод построения, а на iOS это делается с помощью hostedDomain.

Это также выполняется с помощью параметра hd с конечной точкой REST и параметр hosting_domain с API JavaScript.

5. Что... установить в XML SAML, который мы отправляем в URL-адрес Google ACS.

Настройка метаданных поставщика для интеграции SAML

Метаданные SAML используются для обмена информацией о конфигурации между Поставщик удостоверений (IdP) и поставщик услуг (SP). Метаданные для как IdP, так и SP определены в файле XML:

XML файл метаданных IdP содержит сертификат IdP, идентификатор объекта, URL-адрес переадресации и URL-адрес сообщения, например, 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>

XML файл метаданных SP содержит сертификат SP, идентификатор объекта, и URL-адрес потребительской службы утверждений (URL-адрес ACS), например, 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>

Прежде чем использовать SAML для входа в веб-консоль, метаданные из IdP должны быть загружены, а метаданные из SP должны быть сгенерированы. После Сгенерированы метаданные SP, они должны использоваться совместно с IdP. Свяжитесь с нами IdP для получения инструкций по обмену метаданными SP.

Создайте XML файл метаданных поставщика идентификаторов (IdP) с помощью SAML протокол. Для спецификаций метаданных SAML перейдите в Oasis сайт, Метаданные для OASIS Язык разметки безопасности (SAML) V2.0.

Создайте файл хранилища ключей. Информацию о файлах хранилища ключей см. В разделе Создание сертификатов для SAML Интеграция.

Дополнительные сведения об утилите keytool см. в Oracle Веб-сайт документации, keytool - ключ и Управление сертификатами Инструмент.

URL-адреса поставщика услуг SAML

Чтобы настроить G Suite как поставщика идентификации SAML (IdP), вам нужно ввести URL-адреса поставщика услуг SAML для каждого отдельного пользователя предварительно настроенных облачных приложений, которые вы планируете настроить.

Ссылки для объекта ID, ACS URL и стартовые URL-адреса для каждого из предварительно настроенных облаков приложения.

6. Поиск и устранение неисправностей Single Sign-On (SSO)

Этот документпредоставляет шаги для устранения распространенных сообщений об ошибках, возникающих во время интеграции или использования Single Sign-On на основе SAML (SSO) с G Suite, когда Google является поставщиком услуг (SP).