Пропуск кода авторизации против ресурса пароль владельца ресурса для доверенных приложений

Question

У меня возникла проблема с попыткой решить это в моей голове ... Поток кода авторизации, по-видимому, относится к сторонним приложениям, поэтому он делает пользователя предоставить разрешение на приложение на сервере авторизации.

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

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

Это порождает проблему, поскольку они больше не используют поток кода авторизации, они больше не могут использовать cookie сеанса, который пользователь имеет с сервером авторизации ... так как можно сделать SSO между этими двумя разными типы потоков?

Если бы у вас был способ указать доверенные приложения в AuthCode, это уже не будет проблемой, но это не предусмотрено спецификацией и, похоже, ни в одном программном обеспечении OAuth2/OpenID, о котором я знаю.

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

Я хотел бы знать, если кто-то решил эту проблему в других творческих направлениях.

Answer 1

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

Вы можете создать творческий способ получения токена/сеанса SSO и передать его клиенту для проверки через поток ROPC в поле «пароль» на сервере авторизации, но вы будете изобретать тип предоставления авторизационного кода самостоятельно нестандартным образом.

Одним словом: избегайте использования типа полномочий Credentials владельца ресурса, если можете. Это устаревший тип гранта в OAuth 2.0, предназначенный только для использования в сценарии миграции.