Lorawan-stack: Представьте новое приложение учетной записи (для замены приложения oauth)

Ссылки https://github.com/TheThingsIndustries/lorawan-stack/issues/1659

Что касается всей проблемы путаницы входа/выхода между консолью и провайдером oauth, вот мой план:

• Мы используем отдельный логотип Account для приложения учетной записи (вместо логотипа TTS) и используем тот же компонент заголовка, который мы также используем для консоли (cc @pierreph)
• Вместо того, чтобы иметь два отдельных экрана входа в систему для консоли и приложения учетной записи, мы должны связать опыт ближе друг к другу, то есть
  
  
  
  • Мы удалим экран входа в консоль /console/login
  
  
  • Консоль автоматически перенаправит на страницу входа в приложение учетной записи /account/login , если у нее нет (действительного) токена доступа.
  
  
  • Как мы уже делали с кнопкой входа в консоль, мы будем использовать параметр запроса перенаправления, чтобы отправить пользователя обратно в консоль после успешного входа в систему.
  
  
  • Выход из пользовательского интерфейса консоли приведет к удалению сохраненного токена доступа, а также к выходу из приложения учетной записи. Таким образом, пользователям всегда придется повторно вводить свои учетные данные, чтобы снова войти в консоль.
    
    
    
    
    
    • Чтобы иметь возможность сделать это, нам нужен способ инициировать выход из системы из запросов из разных источников (поскольку консоль и приложение учетной записи не обязательно находятся в одном и том же источнике).
    
    
    
    • В v2 мы используем простой маршрут /users/logout , который вызывает выход из системы, на который можно ссылаться из любого места.
    
    
    
    • Было бы неплохо изучить способы достижения того же самого, сохраняя при этом безопасность CSRF.
    
    
    
  
  
  • Новый поток будет очень похож на поток консоли v2; мы в основном пожертвуем разделением клиента консоли и сервера авторизации, чтобы улучшить UX, что нормально, поскольку консоль является своего рода клиентом особого случая.
  
  
  • Возможно, нам придется пересмотреть этот поток, если мы разрешим другие процедуры входа в
  
  

Если я не услышу жалоб на этот план, я начну его реализовывать.

Звучит как отличный план. Я согласен, что нам не нужен явный выход из консоли и оставайтесь в системе через OAuth в пользовательском интерфейсе, хотя это будет работать именно так.

Что нужно для выхода из системы из разных источников? Разве это не был бы простой двухэтапный подход; «страница выхода» для удаления сохраненного в консоли токена доступа, а затем перенаправление на общую страницу выхода, на которой выходит приложение «Учетная запись»? Или вы хотите это без перенаправления, но опубликовать в конечной точке выхода?

Что касается выхода из системы, мы можем почерпнуть вдохновение из выхода из системы OpenID Connect. Хорошее резюме можно найти здесь: https://medium.com/@robert.broeckelmann/openid -connect-logout-eccc73df758f

Звучит как отличный план. Я согласен, что нам не нужен явный выход из консоли и оставайтесь в системе через OAuth в пользовательском интерфейсе, хотя это будет работать именно так.

Что нужно для выхода из системы из разных источников? Разве это не был бы простой двухэтапный подход; «страница выхода» для удаления сохраненного в консоли токена доступа, а затем перенаправление на общую страницу выхода, на которой выходит приложение «Учетная запись»? Или вы хотите это без перенаправления, но опубликовать в конечной точке выхода?

Двухэтапный подход — это нормально. Меня беспокоило то, что выход из приложения учетной записи должен быть отключен CSRF, а это означает, что любой, у кого есть ссылка для выхода, может соблазнить кого-то выйти из своей учетной записи. В настоящее время это также возможно со стеком v2 ( щелкнув здесь, вы выйдете из системы ).
Я думаю, что на данный момент это приемлемо, но не совсем лучшая практика.

Я проделал довольно большую работу для нового приложения учетной записи:

• Рефакторинг компонентов и контейнеров, которые могут использоваться консолью и приложением учетной записи.
• Реализован новый дизайн (включая отзывчивость)
• Реализованы настройки профиля, включая изображение профиля
• Реализовано управление авторизациями (просмотр и отзыв)
• Реализовано управление сеансом (просмотр и отзыв)
• Решение проблемы, которая приводила к пустым рендерингам при использовании общих зависимостей модуля css.

Я сделал это, жестко запрограммировав токен доступа, чтобы иметь возможность использовать API стека. В настоящее время я не могу продвинуться вперед с правильной реализацией, так как не знаю, как лучше всего получить токен доступа для приложения учетной записи.
Прямо сейчас «приложение oauth» — это просто SPA, которое подключается к конечным точкам аутентификации сервера oauth (вход в систему, выход из системы и другие конечные точки, связанные с учетной записью, которым не требуется токен доступа).
@htdvisser упомянул мне, что наша первоначальная идея заключалась в том, чтобы приложение учетной записи было отдельным клиентом oauth с использованием типа предоставления пароля. Я думаю, что мы должны открыть дискуссию по этому поводу, поскольку:

• в зависимости от источника тип предоставления пароля не рекомендуется даже для «официальных» и доверенных клиентов.
• это потребует другого экрана входа в систему (рядом с экраном входа в систему провайдера oauth)
• Мне интересно, есть ли способ получить токен доступа напрямую от провайдера oauth без использования другого отдельного клиента, поскольку мы уже выполняем аутентификацию внутри приложения oauth
• если мы используем предоставление пароля для приложения учетной записи, мы должны использовать его и для консоли.

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

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

Итак, мне понадобится помощь и вклад, чтобы продолжить работу с приложением учетной записи. Как мы можем это координировать?

в зависимости от источника тип предоставления пароля не рекомендуется даже для «официальных» и доверенных клиентов.

Да, предоставление пароля не должно использоваться, см. спецификацию и обоснование здесь: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section -3.4

В настоящее время заблокирован # 2148

Итак, после некоторого участия в этом, я думаю, мне нужен некоторый вклад.

Первоначальная идея приложения учетной записи заключалась в том, чтобы заменить текущее приложение oauth и расширить функциональные возможности для управления профилями и сеансами (см. OP). Проблема заключается в том, что для реализации такой функциональности приложению потребуется токен доступа, что, по сути, означает, что приложение учетной записи будет одновременно поставщиком и клиентом OAuth.

Моя идея заключалась в том, чтобы представить новый клиент OAuth ( account ) и внешний интерфейс, чтобы объединить функциональность с текущим приложением OAuth. Для пользователя может показаться, что и поставщик OAuth (вход в систему, регистрация, проверка учетной записи и т. д.), и клиент приложения учетной записи (настройки профиля, управление сеансом, управление авторизацией) являются одним и тем же приложением, в то время как в фоновом режиме это техническое разделение между провайдером OAuth и клиентом. На серверной части клиент учетной записи станет частью пакета oauth . С точки зрения внешнего интерфейса мы также могли бы рассматривать обе вещи как одно и то же приложение, используя одну и ту же точку входа ( account.js ).
Точно так же маршрутизация будет отражать это смешивание, например:

• /account/login для входа по oauth [уровень провайдера OAuth]
• /account/register для регистрации пользователя [уровень поставщика OAuth]
• /account/forgot-password за регистрацию пользователя [уровень поставщика OAuth]
• /account/client/login/ttn-stack для входа клиента (авторизации) [уровень клиента OAuth]
• /account/client/oauth/callback для обмена кодом авторизации [уровень клиента OAuth]
• /account обзорная страница клиента oauth [уровень клиента OAuth]

В качестве альтернативы мы могли бы разделить обе проблемы, оставив провайдера OAuth ( /oauth через pkg/oauth ) как есть и обработав приложение учетной записи ( /account через pkg/account ) как совершенно отдельная вещь, как мы делаем с консолью. В этом случае поставщик OAuth будет нести ответственность только за вопросы аутентификации, включая авторизацию и регистрацию учетной записи пользователя, но не будет иметь собственного аутентифицированного представления, как в настоящее время. Вместо этого после входа в систему он по умолчанию будет перенаправляться в приложение учетной записи, которое затем автоматически извлечет токен.

Я чувствую, что первое решение могло бы избежать некоторой путаницы, которая в настоящее время связана с аутентификацией и управлением учетными записями, но я не могу предвидеть, могут ли оно привести к другим осложнениям. Второе решение кажется чище, но вопрос в том, как коммуницировать/брендировать разделение. Например, должны ли оба по-прежнему сообщаться как «Приложение для учетной записи»? Или это должны быть The Things Stack Single Sign On и The Things Stack Account Application ?

Пожалуйста, дайте мне знать ваше мнение.

Хм, сделав шаг назад, какова цель превращения приложения учетной записи в клиент OAuth? Какие функции через OAuth нам нужны?

• Настройки профиля (имя, электронная почта, изображение профиля)
• Управление сеансом (просмотр, отзыв)
• Управление авторизацией (просмотр, отзыв)
• (Возможно, другие мета-настройки, связанные с TTES, в будущем)

Все они требуют токена доступа, поскольку это единственный способ авторизовать соответствующие RPC.

Нам нужно разделить поставщика OAuth, который может быть внешним, например, «The Things Network Community», и управление пользователями, которое касается управления полями сущности пользователя, хранящейся в The Things Stack, включая точки @kschiffer. написал в комментарии выше.

Наши конечные точки /api/v3/* не принимают аутентификацию с помощью файлов cookie, поскольку они поддерживают CORS. Они работают только с ключами API и токенами доступа.

• Настройки профиля (имя, электронная почта, изображение профиля)
• Управление сеансом (просмотр, отзыв)
• Управление авторизацией (просмотр, отзыв)
• (Возможно, другие мета-настройки, связанные с TTES, в будущем)

Все они требуют токена доступа, поскольку это единственный способ авторизовать соответствующие RPC.

Мы также могли бы сделать это частью консоли, но это означало бы, что консоль будет в некоторой степени смешивать проблемы. Я мог видеть ситуации, когда было бы лучше выполнять управление учетными записями без накладных расходов на все другие функции консоли, но, возможно, это я слишком усложняю 🤷‍♂️.

Как правило, вопрос заключается в том, хотим ли мы видеть консоль только как инструмент для управления делами, связанными с сетью. Мы можем либо открыть его как платформу управления общего назначения для всех вопросов, связанных с TTS, либо мы можем быть более атомарными и придерживаться разделения и использовать разные приложения/клиенты для разных задач. Это стратегический вопрос. Я вижу случаи для обоих.

Я не думаю, что консоль (все консоли, потому что консоль есть в каждом кластере) должна иметь полные права пользователя. Консоли не следует использовать для управления авторизованными клиентами OAuth, сеансами, основным адресом электронной почты и контактной информацией. Лучше иметь специальное приложение для управления пользователями (приложение для учетной записи).

Действительно, хороший момент. Затем он возвращается к первоначальному вопросу .

Мое мнение:

Смешанный подход:

• От точки зрения пользователя менее запутанно (одно место для всех вопросов, связанных с учетной записью)
• Более легкий брендинг / коммуникация
• Соответствие исходному плану приложения учетной записи
• С точки зрения внешнего интерфейса нам не нужна новая точка входа и, следовательно, отдельный шаблон.
• Реализация становится более сложной/запутанной (приложение учетной записи является поставщиком и клиентом oauth)

Раздельный подход:

• Более чистая и традиционная реализация
• Конфигурация более гибкая и понятная
• Представляет новое приложение рядом с приложением oauth, которое нуждается в разумном брендинге и коммуникации.
• Более длинные сборки (могут быть маргинальными, не проверял) и больше активов

Я склоняюсь к смешанному подходу.

• Настройки профиля (имя, электронная почта, изображение профиля)
• Управление сеансом (просмотр, отзыв)
• Управление авторизацией (просмотр, отзыв)
• (Возможно, другие мета-настройки, связанные с TTES, в будущем)

Это приложение для учетной записи, верно? Не OAuth?

• Представляет новое приложение рядом с приложением oauth, которое нуждается в разумном брендинге и коммуникации.

Для чего тогда еще нужно приложение OAuth?

Можете ли вы перечислить функции для пользователя, которые клиент OAuth добавляет в приложение учетной записи, которые мы не можем создать в приложении учетной записи, потенциально через новые конечные точки?

Это приложение для учетной записи, верно? Не OAuth?

Да, это приложение для учетной записи. Но план состоял в том, что то, что у нас сейчас есть в виде приложения OAuth, станет частью приложения учетной записи.

Для чего тогда еще нужно приложение OAuth?

Для аутентификации (в рамках потока OAuth), регистрации пользователя, авторизации клиента, сброса пароля. В основном все, что связано с аутентификацией пользователей и авторизацией клиентов.

Можете ли вы перечислить функции для пользователя, которые клиент OAuth добавляет в приложение учетной записи, которые мы не можем создать в приложении учетной записи, потенциально через новые конечные точки?

Проблема скорее в другом: мы не можем просто расширить наше текущее приложение OAuth функциями, которые мы хотим для приложения учетной записи, поскольку нам потребуется получить токен доступа. Это немного проблема курицы и яйца. Если бы существовали другие средства авторизации для функций приложения учетной записи (сеансы, авторизация и т. д.), например, с помощью файла cookie сеанса, который есть в приложении OAuth, тогда все было бы иначе. Но из того, что я вижу, это невыполнимо.

Является ли приложение OAuth отдельной вещью? Реализует ли он потоки перенаправления для клиентов OAuth? Или это сам клиент OAuth?

Акцент мой:

Моя идея заключалась в том, чтобы представить новый клиент OAuth ( account ) и внешний интерфейс, чтобы смешать функциональность с текущим приложением OAuth . Для пользователя может показаться, что и поставщик OAuth (вход в систему, регистрация, проверка учетной записи и т. д.), и клиент приложения учетной записи (настройки профиля, управление сеансом, управление авторизацией) являются одним и тем же приложением, в то время как в фоновом режиме это техническое разделение между провайдером OAuth и клиентом . На серверной части клиент учетной записи станет частью пакета oauth .

я вижу здесь;

• OAuth-клиент
• текущее приложение OAuth
• OAuth-провайдер
• клиент приложения учетной записи
• провайдер OAuth
• клиент
• серверная часть
• клиент аккаунта
• пакет oauth

Я пытаюсь понять предложение, но я не совсем понимаю, что есть что еще.

Итак, какие функции нам нужны?

1. Зарегистрироваться
2. Забыть пароль
3. Авторизоваться
4. Изменить пароль
5. Просмотр и редактирование профиля
6. Управление сессиями
7. OAuth-вещи
   
   
   
   1. Экран согласия (поток кода авторизации OAuth)
   
   
   2. Управление авторизацией OAuth
   
   

Я предполагаю, что 1-6 можно реализовать, вообще не касаясь OAuth, если мы будем использовать сеансовую аутентификацию. Это возможно, верно?

Да извини. У нас есть ряд нефиксированных терминов, которые затрудняют объяснение. По крайней мере, это дает хорошее представление о сложности вопроса 😅.

Итак, возьмем статус-кво:

OAuth-провайдер
Объект, обеспечивающий авторизацию (а в нашем случае и аутентификацию) согласно спецификации OAuth 2.0. В нашем случае это пакет pkg/oauth , который, в свою очередь, использует приложение OAuth (см. ниже) для реализации необходимого пользовательского интерфейса для получения информации о пользователе (визуализация входа, регистрация, представления авторизации и т. д.).

Приложение OAuth
Это реагирующее веб-приложение на внешнем интерфейсе. Код нашего внешнего интерфейса состоит из разных приложений (с разными точками входа oauth.js / console.js ), которые имеют общие части, такие как реагирующие компоненты и утилиты.

OAuth-клиент
Зарегистрированный клиент, использующий OAuth для проверки подлинности и авторизации, например консоль или интерфейс командной строки.

пакет oauth
Пакет Go, отвечающий за реализацию поставщика OAuth. Это pkg/oauth .

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

Я предполагаю, что 1-6 можно реализовать, вообще не касаясь OAuth, если мы будем использовать сеансовую аутентификацию. Это возможно, верно?

да. 1-4 уже возможны без oauth/токена доступа. 5 и 6 в настоящее время нуждаются в маркере доступа. 7. ii еще не реализован. Если бы 5 и 6 были бы возможны без токена доступа, тогда нам действительно не понадобился бы другой клиент oauth для этого. Тем не менее, нам нужно учитывать, что каждая функциональность, которую мы, возможно, захотим добавить в приложение учетной записи в будущем, не должна использовать токен доступа в качестве единственного средства авторизации.

Если бы 5 и 6 были бы возможны без токена доступа, тогда нам действительно не понадобился бы другой клиент oauth для этого. Тем не менее, нам нужно учитывать, что каждая функциональность, которую мы, возможно, захотим добавить в приложение учетной записи в будущем, не должна использовать токен доступа в качестве единственного средства авторизации.

Правильно. Это имеет для меня большой смысл. Это также лучшая основа для «режима sudo», когда пользователи могут делать что-то _только_ в приложении учетной записи, например, после повторного ввода пароля. Так что да, может быть некоторое совпадение между тем, что могут делать клиенты OAuth и приложение учетной записи, но мне это совпадение не кажется большим. Я вижу ценность в сохранении вещей, посвященных приложению учетной записи.

Ладно, звучит хорошо.
@htdvisser У вас есть возражения? А если нет, можете ли вы указать мне соответствующие файлы/пакеты для авторизации, потому что я полагаю, что у вас не будет времени заниматься этим в ближайшее время (?).

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

Наш API — это gRPC, а аутентификация выполняется с заголовком Authorization , который распространяется на gRPC как метаданные запроса. Реализация сеансовой аутентификации может выглядеть так:

• Добавьте тип SessionToken к pkg/auth/auth.go
• Добавьте секретную часть в модель Session , аналогично тому, что мы делаем с ключами API и токенами доступа.
• Добавьте промежуточное ПО, которое извлекает идентификатор сеанса и секрет сеанса из файла cookie и перенаправляет их в заголовок Authorization в виде SessionToken.
• Добавьте SessionToken как case к switch tokenType { в pkg/identityserver/entity_access.go

Здесь следует учитывать одну вещь: это также означает, что приложение учетной записи и API версии 3 должны обслуживаться из одного и того же источника. В противном случае аутентификация с помощью файлов cookie не будет работать, поскольку контекст аутентификации включает разные источники.
Не уверен, насколько это приемлемо. По крайней мере, на практике кажется, что мы используем одно и то же происхождение в наших развертываниях.

Да, они будут одного происхождения.

@kschiffer, пожалуйста, сообщите нам, как мы можем разблокировать прогресс здесь.

Я написал резюме здесь: https://github.com/TheThingsNetwork/lorawan-stack/pull/2850#issuecomment -657497193

Хорошо, давайте продолжим этот разговор здесь.

@kschiffer Немного поработав над этим:

• Интерфейсная часть приложения oauth будет в основном состоять только из экрана авторизации.

да

• Я думаю, что очень раздражает необходимость сохранять конфигурации is.oauth.ui.* только для этого.
  [...]
• Я также немного не уверен в точных ограничениях того, как мы можем изменить конфигурацию стека, не нарушая CC.
• Мне немного не повезло найти здесь жизнеспособное решение, и мне действительно нужен некоторый вклад

Мы не можем сломать конфигурацию в версии 3, но мы можем ввести новую конфигурацию, отказаться от старой конфигурации, использовать старую конфигурацию в качестве резервной и зарегистрировать проблему TODO с пометкой bump/major чтобы удалить старую конфигурацию.

Поэтому я предлагаю ввести новую конфигурацию, которая будет полной заменой и позволит использовать новое приложение учетной записи. Для обратной совместимости он должен работать без указания пользователем этой новой конфигурации, т.е. полагаться на нормальные значения по умолчанию и старую конфигурацию через is.oauth.ui.* .

@kschiffer, какой здесь статус?

В настоящее время перебазирую свою работу над новыми эшафотами, которая продолжается здесь: #3453.

Далее следует перебазирование, исправление и PR-проверка аутентифицированных представлений, а также адаптация текущих дизайнов к новому брендингу.

@kschiffer, какой здесь статус?

Приложение Account было представлено в версии 3.11. В настоящее время все еще отсутствуют:

• Смена аккаунта #488
• Управление сеансом
• Управление авторизацией (iirc также включает добавление конечных точек API)

В ПОРЯДКЕ. https://github.com/TheThingsNetwork/lorawan-stack/issues/488, кажется, уже закрыт.

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