Чек-лист безопасности

Calab сам закрывает многие классы атак: точное сравнение redirect URI, обязательный PKCE, одноразовые коды, ротация refresh с отзывом цепочки при повторе, проверка прав при каждом обмене. Но часть защиты — на стороне вашего приложения. Пройдите по списку до запуска.

Запрос авторизации#

• Для каждой попытки входа генерируются новые code_verifier, state и nonce криптостойким генератором и хранятся на сервере (или в защищённой cookie), а не в URL.
• code_challenge_method=S256 — всегда, для любого типа клиента.
• Запрашиваются только нужные scopes; email — только если он действительно нужен.
• Issuer и эндпоинты берутся из discovery нужного пространства, а не собираются из пользовательского ввода.

Ответ на redirect URI#

• state сверяется с сохранённым; при несовпадении вход прерывается.
• Параметр iss сверяется с ожидаемым issuer (защита от подмены провайдера).
• Страница callback не выводит code в логи, аналитику и заголовок Referer (ставьте Referrer-Policy: no-referrer).
• error=access_denied и другие ошибки обрабатываются без падения и без повторного автоматического редиректа по кругу.

Обмен кода и токены#

• Секрет клиента хранится только на сервере, в менеджере секретов, и никогда не попадает в браузер или мобильное приложение. Публичные клиенты (SPA, нативные) секрета не имеют вовсе.
• Клиент аутентифицируется заголовком Authorization: Basic, не телом запроса.
• ID token проверяется полностью: подпись RS256 по JWKS, iss, aud = ваш client_id, exp, nonce. Алгоритм фиксирован (RS256), none и HS* отвергаются.
• Учётная запись связывается по паре (iss, sub), а не по email или имени.
• Access и refresh token не пишутся в логи; refresh token хранится зашифрованным.
• Обновление токенов выполняется последовательно; новый refresh token сохраняется до использования нового access token.
• invalid_grant и invalid_token приводят к новому входу, а не к бесконечным повторам.

Конфигурация клиента#

• Зарегистрированы только нужные redirect URI, все — https:// (у нативных — loopback или своя схема).
• У SPA перечислены только собственные origins.
• «Разрешить продолжение доступа» включено, только если приложению действительно нужен доступ дольше 5 минут.
• Есть процедура смены секрета: вы знаете, что смена отзывает все доступы, и готовы к повторному входу пользователей; для плановой смены используйте 10-минутное окно.
• Удалены клиенты, которыми больше не пользуются.

Выход и отключение#

• При выходе из приложения или отключении интеграции вызывается /revoke.
• Вы помните, что отзыв доступа в Calab не завершает сессию в вашем приложении: при важных действиях проверяйте доступ через /userinfo или refresh.

Чего не делать#

• Не используйте OAuth access token для вызова API Calab — он там не работает. Для автоматизации есть боты.
• Не встраивайте страницу согласия во фрейм — Calab это запрещает.
• Не полагайтесь на email как на доказательство владения корпоративным ящиком: Calab передаёт только адрес, подтверждённый в аккаунте Calab, и не утверждает ничего о корпоративном IdP.
• Не кэшируйте JWKS навсегда: ключи подписи ротируются оператором.