Cloudflare відкрила OAuth для всіх розробників

Self-managed OAuth тепер доступний кожному розробнику на Cloudflare, ідеться в публікації від 24 червня. Функція дозволяє клієнтам створювати й керувати власними OAuth-клієнтами для делегованого доступу до Cloudflare API замість звернення до невеликої кількості інтеграцій, підключених вручну.

Від API-токенів до делегованого доступу

OAuth не є новинкою для Cloudflare: його роками використовують Wrangler, консольний інструмент для розробників, і партнерські інтеграції, як-от PlanetScale. Але сторонній OAuth був обмежений кількома вручну підключеними партнерами, тож розробники власних інтеграцій мусили покладатися на API-токени — компанія називає їх складнішими в керуванні та погано придатними для делегованих сценаріїв.

Із self-managed OAuth застосунок проходить стандартний потік, у якому користувач надає обмежений доступ напряму. За словами Cloudflare, це спрощує створення SaaS-інтеграцій, внутрішніх платформ для розробників та агентних інструментів, а користувачам дає зрозумілішу згоду й простіше відкликання. Цього року компанія оновила екран згоди, щоб було видно, який застосунок просить доступ і які дозволи отримає, додала керування відкликанням у панель і зробила власників застосунків помітнішими для запобігання OAuth-фішингу.

Оновлення рушія

Відкриття OAuth для всіх вимагало масштабного оновлення рушія під ним — Hydra, відкритого OAuth-сервера, який Cloudflare розгорнула роки тому. Замість одного великого стрибка команда запланувала два послідовні оновлення: спершу до останнього випуску 1.X, потім до 2.X. З'ясувалося, що навіть менший крок блокуватиме критичні таблиці під час міграцій схеми.

Для оновлення до 2.X міграцію на місці відкинули, тож Cloudflare обрала схему blue-green: міграції виконувалися на копії робочої бази, а запис залишався ввімкненим, щоб уникнути простою. Час життя токенів збільшили до кількох годин, аби зменшити кількість нових записів, а кожне відкликання фіксувалося в черзі на Cloudflare Queues, щоб його можна було відтворити після перемикання — це захист від випадкового поновлення доступу, який користувачі скасували. Міграція в продакшені тривала близько трьох годин у вікні низького навантаження.

Перемикання не минуло без проблем. Після кроку 1.X зросла кількість помилок refresh-токенів, бо нова версія анулювала весь ланцюжок токенів, коли refresh-токен використовували повторно, що вдарило по клієнтах із високим навантаженням, як-от Wrangler і MCP-інструменти; Cloudflare додала об'єднання refresh-токенів у Worker, що маршрутизує OAuth-трафік. Після перемикання на 2.X завдання очищення в сервісі авторизації почало видаляти чинні дані політик, що вело до міграції, яка позначила частину дійсних сесій недійсними; компанія відновила дані.

Результати

За словами Cloudflare, після оновлення OAuth-трафік залишається стабільним, а продакшен тепер працює на тій самій основі, на якій у staging перевіряли нові OAuth API. Міграція оновила 132,5 мільйона рядків і вставила 114,7 мільйона, а середня затримка API P95 у Hydra знизилася на 45 відсотків — із 185 мс до 101 мс. Тепер будь-який клієнт Cloudflare може створити OAuth-застосунок із панелі.