Hacker News Digest

Как работает OAuth
Вместо передачи логина-пароля стороннему приложению OAuth выдаёт токен доступа — персональный «ключ» для конкретного пользователя. Приложение использует его, чтобы действовать от имени пользователя без доступа к его паролю.

Классический поток

1. Пользователь нажимает «Подключить банк» в YNAB.
2. YNAB открывает браузер с URL провайдера (например, банка), куда добавляет client_id, redirect_uri, scope и случайный state.
3. Пользователь логинится у провайдера и разрешает доступ.
4. Провайдер перенаправляет обратно в YNAB с кодом авторизации.
5. YNAB обменивает код на токен доступа через безопасный back-end-запрос.
6. С токеном YNAB запрашивает данные счёта.

PKCE
Для мобильных и SPA добавляют code_challenge и code_verifier, чтобы перехват кода не дал злоумышленнику токен.

Refresh-токены
Короткоживущий access token можно обновлять долгоживущим refresh token без повторного логина.

Итог
OAuth разделяет аутентификацию и авторизацию: пользователь доверяет провайдеру, провайдер — приложению, приложение получает минимально необходимые права.

• Участники жалуются, что OAuth/OIDC кажутся простыми, но реальная реализация требует чтения спецификаций и RFC, а поверхностных гайдов мало.
• Несколько человек подтвердили: приходится самим собирать знания из RFC, OIDC-документов и собственных заметок.
• Упомянуты полезные ресурсы — гайд Alex Bilbie, книга Aaron Parecki, страницы Mozilla и RFC-примеры.
• PKCE считается не «менее безопасным», а способом защитить целостность потока; просят отдельный материал о нём.
• Критика стандарта: OAuth 2.0 «скелет протокола», с множеством опциональных частей и историческими уязвимостями.

Кратко о PR #3899
Добавлена поддержка SSO через OpenID Connect (OIDC) в Vaultwarden.

• Что нового

  • Авторизация через внешний OIDC-провайдер (Keycloak, Azure AD, Google и др.).
  • Автоматическое создание/обновление пользователей при первом входе.
  • Настройка через переменные окружения: SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID, SSO_CLIENT_SECRET.
  • Поддержка PKCE и offline_access для refresh-токенов.

• Как использовать

  1. Указать параметры OIDC в .env.
  2. Включить SSO в админ-панели.
  3. Пользователи входят кнопкой «Login with SSO».

• Ограничения

  • Только веб-клиент; мобильные/CLI пока без SSO.
  • Не работает с двухфакторной аутентификацией Vaultwarden (используйте MFA у провайдера).

• Проверено

  • Keycloak, Auth0, Azure AD, Google Workspace.

PR готов к слиянию; дальнейшие улучшения (SAML, группы) в roadmap.

• Внедрённый SSO в Vaultwarden в первую очередь нужен корпоративным и командным средам, где упрощает автоматическое добавление/удаление пользователей и управление доступом к коллекциям паролей.
• Для личного или семейного использования польза минимальна: мастер-пароль всё равно требуется, а SSO не заменяет шифрование.
• Многие админы некоммерческих и малых организаций рады возможности подключить единый OIDC-провайдер вместо ручного приглашения и отслеживания активных волонтёров/сотрудников.
• Часть пользователей обеспокоена безопасностью: просят аудитов, контроля образов Docker и зависимостей.
• SSO не отменяет мастер-пароль: он по-прежнему нужен для расшифровки хранилища, а SSO лишь аутентифицирует пользователя.