У червні ми вбудували шар ідентифікації в застосунки, які генерує OwlMeans.
Видимою частиною був екран входу. За ним стояли облікові записи, сесії, дозволи й межа між користувачами нашої платформи та користувачами застосунку клієнта.
Я хотів, щоб ці рішення від самого початку були частиною архітектури застосунку.
Облікові записи та вхід
Успішний вхід повідомляє застосунку, хто прийшов. А от що цій людині можна читати чи змінювати, вхід не вирішує.
Клієнтові може знадобитися користувач, який бачить свої записи, оператор, який опрацьовує чергу, і адміністратор, який керує доступом. Навіть коли екрани схожі, це різні зони відповідальності.
Пояснення OpenID Connect на сайті OpenID Foundation описує протокол ідентифікації. А дозволи все одно залежать від бізнес-правил застосунку.
У червні ми підʼєднали процес входу до згенерованого застосунку й запровадили спільний спосіб описувати доступ. Так решта коду отримала єдину основу, на яку може спиратися.
Але політику кожного клієнта ми за нього не визначали.
У нашій реалізації кінцеві користувачі застосунку входили з одноразовими обліковими даними, які надходили на пошту. Так згенерованому застосунку не знадобився окремий процес керування паролями.
Я не назвав би вхід через пошту загальною гарантією безпеки й не ставив би його на один рівень із сильнішими методами автентифікації.
Над шляхом доставки, відновленням облікового запису й поведінкою сесій ще треба подумати. А також над тим, як людина стає членом організації клієнта.
Ці деталі легко проґавити, якщо під час приймання перевіряють лише те, що форма входу надсилається.
Межі доступу
Саме модель дозволів я хотів уберегти від розпорошених ситуативних рішень.
Вимогу до доступу може мати екран, але й операції за ним потрібна вимога, яку справді перевіряють. Сховати кнопку не означає задати правило авторизації.
У шпаргалці OWASP з авторизації радять визначати межі доступу, за замовчуванням відмовляти в доступі й перевіряти дозволи на рівні запитів. Там же закликають ці правила тестувати.
У структурі наших застосунків вимогу оголошують через домовленості фреймворку щодо доступу. Бізнес-код має послідовно спиратися на ці домовленості, а не вигадувати власне тлумачення в кожному обробнику.
У звичайному робочому інструменті я тестував би реальні відмінності. Користувач може переглядати свій запис. Оператор може опрацювати призначений йому запит. Жоден із них не повинен отримати адміністраторський доступ лише тому, що увійшов.
Таку поведінку треба зафіксувати у вимогах до продукту й у тестах. Сама назва протоколу її не забезпечить.
В OwlMeans є свої облікові записи. У застосунку, створеному за його допомогою, — кінцеві користувачі. Розвести ці речі було частиною роботи над ідентифікацією.
Межі на рівні клієнтів, проєктів і ресурсів важливі, бо користувача можна успішно ідентифікувати, а конкретна дія все одно не входитиме до його повноважень. Самого ідентифікатора користувача замало, щоб виразити всі ці межі.
Виробничому середовищу теж потрібна своя конфігурація входу, задумана саме для нього. Облікові записи й адреси перенаправлення, якими користувалися під час попереднього перегляду, не слід вважати налаштуваннями виробничого середовища.
На практиці питання таке: чи може потрібна людина пройти задуманий робочий процес і чи отримає відмову той, хто перебуває за цією межею.
OIDC і передача застосунку
OIDC дає застосунку стандартний інтерфейс ідентифікації. Проте з цього не випливає, що доступна будь-яка інтеграція з корпоративними системами ідентифікації, що кожну межу між орендарями протестовано або що анкету покупця щодо безпеки заповнено.
У попередній версії цієї статті це звучало так, ніби все стається саме собою.
Інтеграція, як і раніше, залежить від провайдера та конфігурації. Ролі клієнта й правила його організації ще треба описати. Згенерований застосунок і далі треба переглядати, перш ніж передати клієнтові.
Я волію описати частини, які в нас є, ніж натякати на сертифікацію лише тому, що ми обрали протокол.
У серпні інтегрована система ідентифікації стала єдиною реалізацією IAM на Платформі. Червневі міркування про замінний зовнішній бекенд — уже історія.
Теперішня робота над доступом також відділяє реалізовані засоби контролю від доопрацювань, над якими ще працюють. Документація й код свідчать про сам механізм. Але вони не можуть довести, що кожен застосунок, створений на його основі, безпечний.
Актуальний посібник з автентифікації пояснює складові фреймворку. А те, як влаштовано доступ у застосунку, треба перевіряти з огляду на продукт, який створюють.
Якщо ідентифікацію вбудовано, цю частину системи підтримуємо ми. Клієнтам усе ще треба описати людей, ресурси й дії, яких потребує їхній продукт. Спільний спосіб виражати ці правила в нас є. А перевіряти їх — досі частина роботи.
Переглянуто 15 жовтня 2026 року. Історію червневої реалізації збережено, а колишні порівняння цін і розмашисті обіцянки щодо корпоративного рівня та безпеки виправлено.