Поток # 2 предпочтителен, и вот почему я так считаю:
Критическим элементом в потоке # 1 является шаг 1.6, где файлы cookie app1 оцениваются на срок действия. Ключевым моментом здесь (на мой взгляд) является то, что файлы cookie должны быть привязаны к конкретному приложению, а файлы cookie app1 не должны проверяться при аутентификации пользователя app2 .
И наоборот, в потоке # 2 шаг 2.6 должен выполняться app1 (в качестве источника ссылки), поэтому app1 и провайдер идентификации соглашаются, что токен аутентификации по-прежнему действителен и app2 может продолжить использование app1 в качестве приложения отложенной аутентификации.
IdP может законно проверять (или обновлять) токен из любого приложения, в то время как cookie-файл должен управляться как специфичный для приложения (или сеанса).
3-й более идеальный метод:
Каждое приложение должно иметь свой собственный контекст аутентификации из IdP , и когда app1 аутентифицируется, каждое из связанных приложений может аутентифицироваться также с теми же учетными данными пользователя. В этом шаблоне приложения могут истекать токены в разное время (например: просмотр 2 часа, но редактирование только 30 минут.)
Ключом к этому подходу является то, что к учетным данным единого входа обращаются один раз, проверяют подлинность для всех контекстов приложения, а с этого момента время жизни токенов управляется для каждого приложения.