Oauth SSO для приложений REST

Question

Я создаю (набор) веб-приложений; бэкэнд имеет REST-подобный API, интерфейсом будет некоторое приложение REST JS, приложения для Android и т. д .; и я пытаюсь придумать функциональность SSO.

Глядя на Oauth2/OIDC, кажется, лучший способ - использовать неявный поток; однако токены доступа в неявном потоке (в oidc) имеют истечение набора. Ток обновления не является частью неявного потока.

Как я могу гарантировать, что пользователь останется в системе? То есть когда токен доступа истекает, внешнее приложение попытается получить новый с сервера auth; который должен запрашивать имя пользователя/пароль. В качестве альтернативы, он может построить сеанс с интерфейсом (используя файлы cookie), но как это отличается от токена обновления?

Мне кажется, что получение токена доступа, например, из приложения Android, по крайней мере, открывает веб-браузер; в зависимости от длины истечения, что может быть довольно часто. Это правильный поток или я что-то упускаю?

Answer 1

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

Вы можете проверить, действительно ли пользователь выполнил вход, отправив запрос авторизации с параметром запроса prompt=none (см. Раздел 3.1.2.1. Authentication Request). Я рекомендую вам отправить текущий идентификатор токен с помощью параметра id_token_hint запроса, как указано в том же разделе:

ID Токен ранее выданный сервером авторизации передаются в качестве подсказки о текущей или прошлой авторизованной сессии для конечного пользователя с Клиентом. Если конечный пользователь, идентифицированный идентификатором ID, вошел в систему или выполнил вход по запросу, сервер авторизации возвращает положительный ответ; в противном случае он ДОЛЖЕН возвращать ошибку, например login_required. Когда это возможно, id_token_hint ДОЛЖНО присутствовать, когда подсказка = нет используется

Если вы получите сообщение об ошибке (login_required или interaction_required), то пользователь может выйти из системы.

Другим способом может быть использование функции Session Management. Но поскольку эта спецификация еще не утверждена (проект 27), она может быть изменена и может быть недоступна. Однако это очень простой способ узнать статус пользователя.