OAuth/OpenID на основе браузера с постоянным входом

Question

У нас есть обычное веб-приложение с авторизацией на основе файлов cookie, и теперь мы хотим разделить интерфейс и бэкэнд (api), чтобы иметь сторонний публичный API. Таким образом, наш бэкэнд будет на одном домене и на другом.

Для получения авторизации мы бы хотели переключиться на OAuth 2 with JWT. В этом случае наш интерфейс приложение будет использовать access_token вместо печенья сессии и это приносит большой старый вопрос:

Как оставаться в системе - The Infamous «Запомнить меня» Checkbox (часть II от Form based authentication for websites)

С точки зрения OAuth2 наше приложение для внешнего использования будет использовать что-то между Resource Owner Password Credentials Grant и Implicit Grant. Он ближе к Credentials Credentials Grant, так как мы по-прежнему будем использовать обычную регистрационную форму и не будем перенаправлять пользователя в другой домен для входа. В то же время он ближе к Implicit Grant, поскольку он все собирается только для браузера & JavaScript основан на том, что access_token будет сохранен в браузере.

RFC, says сервер авторизации НЕ ДОЛЖЕН выдавать токен обновления, если вы используете неявной Грант и мой вопрос, если он по-прежнему действует в этом прецеденте, когда вы на самом деле не использовать партию OAuth 3-D, но ваш собственный api? Инстинктивно я чувствую, что наличие refresh_token в браузере - это дыра в безопасности и хотел бы подтвердить это с вами, ребята, но refresh_token, кажется, единственный способ иметь постоянный вход в систему так же, как у нас с файлами cookie.

---

UPD после @FlorentMorselli комментарий:

OpenID функции до сих пор не ответили на мой вопрос, могу ли я использовать refresh_token с браузером только приложением

• Google says они обеспечивают refresh_token только для access_type=offline
• OpenID Connect Core says вы не можете использовать токен обновления с неявным потоком
• OpenI нет D Connect Ядро says ничего об использовании refresh_token с гибридным Flow
• Там только one place, где он говорит что-то многообещающий о refresh_token с гибридным Флоу, но ничего определенного

---

UPD2 благодаря @reallifelolcat

Похоже, что OpenID Connect явно не поддерживает Resource Owner Password Credentials Grant, что означает, что необходимо перенаправить пользователя на сервер OpenID Connect для входа в систему. Вы знаете, есть ли другой способ аутентификации с учетными данными пользователя через OAuth 2.0?

---

Я считаю, что расщепление апи и интерфейс становится все более распространенным в эти дни, и я был бы признателен, если бы вы рассказать, как можно решить эту Persistent Войти вопрос и если вы уроните его полностью и пользователь силы повторно логин каждые X недель.

Спасибо!

Answer 1

Доступ к токенам и токенам обновления не имеет ничего общего с . Вход с OpenID Connect. Это только для авторизации доступа к информации профиля пользователя и, возможно, к заверенным вызовам службы в ваш общедоступный API после факта входа. Обратитесь к спецификации за разницу между токеном ID и токеном доступа.

Если вы собираетесь использовать OpenID Connect для входа в систему, то из того, что вы написали до сих пор, похоже, что вам нужно разместить собственный поставщик OpenID (OP), так как вы хотите избежать перехода в другой домен, чтобы подписать в:.

мы по-прежнему будем использовать обычную форму входа и не будет перенаправлять пользователя на другой домен, чтобы подписать в

Если вы хотите быть вашей собственной идентичности поставщика, то больше мощности тебе. Это означает, что вам придется развернуть свой собственный рабочий экземпляр сервера OpenID Connect в комплекте с авторизацией и конечными точками токена.

Теперь это часть вашего постоянного входа. Ваш браузер webapp будет полагаться на сервер OP, который у вас есть. Когда пользователь пытается подключиться к вашему браузерному приложению с помощью OpenID Connect, им необходимо будет пройти проверку подлинности на ваш OP-сервер. Проходя через поток OIDC, ваше приложение-браузер получит идентификационный токен, содержащий пару эмитента/субъекта, идентифицирующую пользователя.

Это до вас, чтобы определить, каким образом пользователь остается зарегистрированным в вашем OP-сервер, но до тех пор, пока пользователь, по крайней мере разрешает приложение браузера раз: http://openid.net/specs/openid-connect-core-1_0.html#Consent , то вы можете сохранить, что согласие на все будущие запросы в браузере приложение для входа в систему и, следовательно, поддерживать постоянный вход в систему.

Вам нужно будет рассмотреть, как вы собираетесь обрабатывать сеансы управления, но похоже, что у вас уже есть какая-то печенья, чтобы вы могли это использовать (см. Этот ответ: OpenID sign in mechanism - Stay signed in). В противном случае вы столкнетесь с ситуацией, когда ваш браузер webapp должен все время получать новый токен.

Также, как отметил Флорант, вы должны учитывать соображения безопасности при создании публичной клиентской вещи, которую будет использовать ваш веб-браузер на основе браузера. Пример: https://tools.ietf.org/html/rfc6749#section-10.16