Вы используете концепцию под названием OAuth 2.0 / OpenID Connect федерация . Вместо того чтобы быть стандартом, поставщики удостоверений используют эту интеграцию с внешними поставщиками удостоверений.
Случай 1 , исключительно используйте OAuth 2.0 и OpenID connect. SPA просто полагается на сервер авторизации для выдачи токенов.
В Случай 2 вы полагаетесь на внешнего поставщика удостоверений (например, - Google в вашем объяснении) для аутентификации пользователя. И если вы сравниваете свои конфигурации, вы настраиваете IDaaS в качестве клиента для Google. И тогда ваш SPA будет клиентом IDaaS.
Является ли этот вариант использования комбинацией двух потоков OIDC?
Нет, используется тот же поток OIDC. Но вместо того, чтобы SPA напрямую связывался с Google, IDaaS делает запрос (точнее, пересылает запрос) IDaaS создаст запрос авторизации и направит SPA на страницу входа Google. Это делается с помощью IDaaS, получающего зарегистрированные данные, такие как URL-адрес перенаправления, идентификатор клиента и секрет клиента.
Как клиент, вы получаете страницу входа и предоставляете учетные данные. После этого перенаправление OAuth 2.0 / OpenID Connect происходит в IDaaS (Примечание. В Google мы настроили URL-адрес перенаправления в IDaaS). IDaaS получит перенаправление и обработает его. В зависимости от используемого потока в шаге будет задействован запрос токена. Затем он переходит к обработке токена.
На этом этапе внутренне IDaaS заменит токен . Сначала он проверит выданный Google токен. Если токен действителен, IDaaS создаст новый токен с заявками, требуемыми от Google, а также для значений аудитории и эмитента, установленных на известные значения SPA.
В основном IDaaS получает оригинальный токен Google. SPA получает IDaaS созданный токен . Это тот же поток, но со средним IDaaS, работающим с внешним поставщиком удостоверений.