Я создаю проверяющую сторону (RP), которая будет интегрироваться с поставщиками удостоверений (IdP), предоставляемыми клиентами (сначала OpenID Connect, но, возможно, SAML позже), во многих случаях мы ожидаем, что эти IdP станут поставщиками SaaS, где наши клиенты не имеют полного контроля над IdP. Для наших конкретных клиентов RP также нет полного контроля над нашим приложением (т.е. они не могут манипулировать БД).
Мне интересно, как в реальном мире мы будем поддерживать потоки, где пользователи миграция между IdP (скажем, например, пользователи решают мигрировать и хотят сохранить профили в наших приложениях). Как правило, в этих случаях это не тот же рабочий процесс, что и объединение двух идентификаторов, когда вы запрашиваете у пользователя согласие.
Мое чтение spe c и решение Academi c будет что пользователи идентифицируются только по iss и sub, поэтому пользователи в нашей системе будут связаны с несколькими наборами iss и sub, а когда клиенты хотят мигрировать, они экспортируют списки из своего текущего IdP, поставьте сопоставление новым iss и sub и загрузите его в нашу систему. Я не уверен, что многие IdP позволяют вам экспортировать эти данные или использовать этот поток. Интересно, в большинстве случаев они просто используют или предполагают, что существует какой-то другой стабильный идентификатор, , даже если он противоречит спецификации c.