Чому OAuth вже не є найскладнішою частиною Identity Platform

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Коли я зіткнувся із завданням розробки та супроводу Identity Platform, мені здавалося, що найскладнішою частиною буде реалізація OAuth 2.0 та OpenID Connect.

Виявилося, що це не так.

Сьогодні існують зрілі рішення, такі як OpenIddict, Keycloak, Duende IdentityServer, Auth0 та інші. Вони вже вирішують основні завдання протоколу: випуск токенів, перевірку підписів, підтримку PKCE, refresh tokens та інші можливості OAuth/OIDC.

Справжні складнощі починаються після того, як OAuth вже працює.

З’являється новий API — його потрібно зареєструвати як ресурс.

З’являється новий застосунок — потрібно створити OAuth-клієнта.

Для SPA потрібно налаштувати Redirect URI та CORS.

Для сервісів — визначити permissions.

Для нового tenant — підготувати власну конфігурацію.

Для середовищ — створити та керувати криптографічними ключами.

Кожне з цих завдань окремо досить просте.

Але коли таких операцій стає багато, вони перетворюються на постійну операційну роботу.

Тоді виникає питання:

Чому конфігурація Identity Platform досі в багатьох випадках створюється вручну?

В інших сферах розробки автоматизація вже стала стандартом.

Infrastructure as Code дозволяє описувати інфраструктуру.

Хмарні платформи автоматично створюють ресурси.

CI/CD автоматично збирає та розгортає застосунки.

Але Identity Platform часто все ще вимагає від адміністратора відкрити консоль керування та вручну створювати клієнтів, scopes, permissions та інші налаштування.

Хоча більша частина цієї конфігурації добре формалізована.

Наприклад, при створенні нового API система могла б автоматично:

• зареєструвати ресурс;
• створити permissions;
• згенерувати scopes;
• зробити їх доступними клієнтським застосункам.

При створенні SPA-застосунку:

• створити OAuth client;
• згенерувати Client ID;
• налаштувати Redirect URI;
• створити CORS-політику;
• увімкнути PKCE;
• призначити необхідні дозволи.

При створенні нового tenant:

• створити ізольоване середовище;
• підготувати ресурси та клієнтські застосунки;
• випустити криптографічні ключі;
• налаштувати необхідні політики безпеки.

Для цього не потрібно змінювати OAuth.

OAuth 2.0 та OpenID Connect вже чудово вирішують завдання автентифікації та авторизації.

Наступний крок — автоматизація всього, що знаходиться навколо цих протоколів.

Реєстрація ресурсів, створення клієнтських застосунків, керування scopes та permissions, налаштування CORS, підготовка tenant та керування ключами — це повторювані операції, які добре підходять для автоматизації.

Саме ця ідея лягла в основу SolNeat Identity.

Для практичного ознайомлення з платформою можна переглянути відео, де показано процес створення та налаштування Identity Platform:

Мета була не створити ще одну реалізацію OAuth.

Мета — зменшити кількість ручної роботи під час супроводу Identity Platform та автоматизувати якомога більше етапів її життєвого циклу.

Мені здається, що Identity Platform будуть розвиватися в тому ж напрямку, що й інфраструктура та доставка програмного забезпечення.

Автоматичне створення ресурсів, клієнтів, scopes, політик безпеки та криптографічних ключів з часом може стати такою ж звичною практикою, як сьогодні Infrastructure as Code та CI/CD.