Authorization

/invoices/1002

Admin:

IAM здатна керувати доступом до:

- Bob: read Feature flag відповідає:

Access Control

Файлові системи теж мають authorization. * Frontend authorization покращує UX, але не виступає як security boundary. * Практики cloud IAM, Kubernetes RBAC, database permissions, audit logging і multi-tenant SaaS security. Author здатна створювати drafts, Editor здатна редагувати чужі статті, Publisher здатна публікувати, Admin здатна керувати plugins і users.

Критично: “Дамо admin, щоб не було проблем” — один із найшвидших шляхів до серйозної проблеми безпеки. Зловмисник здатна викликати endpoint напряму. * плутати login з доступом;

• перевіряти права тільки на frontend;
• приховувати кнопку, але не захищати API;
• давати всім admin;
• не перевіряти ownership;
• не перевіряти tenant_id;
• довіряти role з client payload;
• робити hardcoded checks у різних місцях;
• не тестувати заборонені сценарії;
• не логувати admin actions;
• не відрізняти 401 і 403;
• використовувати wildcard permissions без потреби;
• не перевіряти JWT signature;
• зберігати занадто довгі access tokens;
• не відкликати доступ після зміни ролі.

  Admin actions можуть включати:
  
  * пояснює, чому дія недоступна;
  * не показує зайві admin controls;
  * показує правильні empty states;
  * пропонує попросити доступ;
  * не розкриває зайві details;
  * відрізняє “немає доступу” від “ресурс не існує” там, де це безпечно.=== SaaS workspace ===
  == Приклад простої RBAC-моделі ==
  |-
  | Authentication
  | Хто ти? '''Практична роль:''' RLS переносить частину авторизації ближче до даних, а не лише до application code. * приховати недоступну кнопку;
  * показати правильне меню;
  * вимкнути action;
  * перенаправити з недоступної сторінки;
  * показати повідомлення про доступ;
  * адаптувати navigation. конкурентні переваги
  Приклад:
  - content.create
  
  Проблеми:
  
  * user profiles;
  * personal documents;
  * orders;
  * comments;
  * messages;
  * uploaded files;
  * private notes;
  * individual settings. Краще:
  
  </div>
  
  У session-based applications користувач системи входить у систему, а сервер зберігає session.== Authorization у Cloud IAM ==
  У cloud platforms authorization часто реалізується через IAM. Це платформа правил, яка захищає кожну важливу дію й кожен важливий ресурс. * read;
  * create;
  * update;
  * delete;
  * approve;
  * export;
  * invite;
  * publish;
  * deploy;
  * refund;
  * manage users. Це означає:
  
  RBAC добре підходить для:
  invoice.refund
  Приклад:
  == конкурентні переваги хорошої авторизації ==
  - Team Finance: read
  Service layer часто виступає як хорошим місцем для resource-specific authorization. '''ABAC''' або '''Attribute-Based Access Control''' — модель, де доступ залежить від attributes.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
  
  </div>
  
  <div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
  
  * багато ролей;
  * багато типів ресурсів;
  * teams або organizations;
  * multi-tenant architecture;
  * sharing;
  * admin panel;
  * billing roles;
  * external integrations;
  * compliance;
  * sensitive data;
  * field-level permissions;
  * approval workflows;
  * enterprise customers. '''Authorization''' — це ключова частина безпеки застосунків, яка визначає, хто має право виконувати конкретні дії над конкретними ресурсами. Authorization має перевіряти:
  Приклад ідеї:
  
  '''Policy engine''' — компонент, який приймає рішення для бізнесу про доступ. const project = await projectRepository.findById(projectId);
  
  Policy здатна відповідати на питання:
  
  <div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
  
  * `user.read`;
  * `user.update`;
  * `project.create`;
  * `project.delete`;
  * `invoice.view`;
  * `invoice.refund`;
  * `settings.manage`;
  * `admin.access`;
  * `report.export`;
  * `billing.manage`. * owner здатна читати й писати;
  * group здатна читати;
  * others не мають доступу. Приклад
  == Authorization у Microservices ==
  <div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
  

app.delete('/projects/:id', requirePermission('project.delete'), deleteProject);

• чи користувач системи authenticated;
• чи має permission на action;
• чи має доступ до конкретного resource;
• чи належить resource до його tenant або organization;
• чи не перевищено scope token;
• чи дає можливість subscription plan цю дію. без зусиль розпарсити token недостатньо.

• system admin;
• organization owner;
• workspace admin;
• project manager;
• member;
• guest;
• billing admin;
• read-only auditor. критично: успішний login не означає автоматичний доступ до всіх ресурсів. Критично: IDOR — одна з найпідступніших authorization-помилок, бо endpoint здатна виглядати абсолютно нормальним. RBAC або Role-Based Access Control — модель авторизації, де доступ визначається ролями.</syntaxhighlight>

</syntaxhighlight>

Authorization застосовується для для контролю доступу до:

'''Головне правило:''' кожна важлива дія має відповідати на три питання: хто діє, що хоче зробити й над яким ресурсом. Приклади дій:
<syntaxhighlight lang="json">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Чи не довіряємо role з client payload? Часто потрібні окремі ролі для billing, users, security, content і integrations. Permission краще формулювати конкретно, а не занадто загально. Чи увімкнена функція? Приклад SQL-ідеї:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''Privilege escalation''' — ситуація, коли користувач системи отримує більше прав, ніж мав. складних правил забезпечується через '''критично:''' ABAC корисний; так само реалізовано але його важче пояснювати, тестувати й audit-ити. Admin authorization має бути особливо обережною. Але resource-level checks часто все одно треба робити в service layer. Простіша модель доречна, якщо:
Feature flags можуть впливати на доступ до функцій, але не завжди виступає як повною authorization-моделлю. - project.create

{
користувач системи із tenant A здатна відкрити resource tenant B через зміну ID в URL. CI service account здатна deploy-ити application, але не здатна читати billing або видаляти production database. Поганий UX:

- organization.manage

== ACL ==

'''Authentication''' і '''authorization''' часто плутають, але це різні речі. Приклад:

}

* користувачу;
* ресурсу;
* дії;
* організації;
* середовищу;
* часу;
* location;
* device;
* security level;
* subscription plan. Код

</div>

== Коли authorization можна спростити ==

* `sub`;
* `iss`;
* `aud`;
* `exp`;
* `iat`;
* `role`;
* `scope`;
* `tenant_id`;
* `permissions`. - billing.manage
Приклад:
Чи виступає як resource-level checks?</div>
</div>
Чи виступає як least privilege?<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
- article.update
Приклад:

Backend authorization — головне місце перевірки доступу. це бізнес-процес перевірки, що користувач системи, сервіс або платформа має право виконати певну дію або отримати доступ до певного ресурсу виступає ключовою рисою '''Authorization''' або '''авторизація'''. '''Row-Level Security''' або '''RLS''' — механізм, який обмежує доступ до рядків у таблиці. "role": "admin"

'''Найлюдяніший факт:''' authentication — це показати паспорт на вході, а authorization — це перевірити, чи маєш ти ключ саме від цієї кімнати. ServiceAccount із зайвими правами здатна стати шляхом до компрометації кластера.</div>

Практична роль: policy перетворює бізнес-правило доступу на перевірне технічне правило. Підходи:

User A не здатна переглянути invoice User B. Насправді login лише підтверджує особу.

throw new Error("Forbidden");

Unix-приклад:

RBAC

Якщо немає правила — дозволити. * Зміна ролі користувача — це security-sensitive action. Чи логуються admin actions? | користувач системи здатна редагувати тільки свої документи |}

</syntaxhighlight> Authorization middleware — проміжний шар, який перевіряє доступ перед виконанням endpoint. * короткоживучим;

• захищеним;
• переданим через HTTPS;
• перевіреним на backend;
• обмеженим потрібними scopes;
• відкликаним або заміненим при ризику. Критично: authorization bug часто не видно в happy path тестах.== JWT Claims ==

Приклад payload: </syntaxhighlight>

allow

* відділяти authentication від authorization;
* перевіряти доступ на backend;
* використовувати deny by default;
* застосовувати least privilege;
* перевіряти доступ до конкретного resource;
* писати негативні authorization tests;
* не довіряти client-side checks;
* не зберігати зайві права в token без контролю;
* робити audit logs для важливих дій;
* регулярно переглядати roles і permissions;
* уникати однієї ролі admin для всього;
* обмежувати service accounts;
* перевіряти tenant boundary;
* документувати permission model;
* не показувати зайву інформацію в error responses;
* тестувати IDOR-сценарії. * витоку даних;
* IDOR;
* privilege escalation;
* доступу до чужих акаунтів;
* незаконних змін;
* несанкціонованого export;
* фінансових втрат;
* порушення privacy;
* втрати довіри;
* compliance-проблем;
* компрометації admin panel;
* зламу multi-tenant isolation. '''критично:''' ownership-перевірка має бути на backend. Authorization здатна перевіряти:
Приклади ролей:
- content.read

Авторизація здатна базуватися на ролях, permissions, attributes, ownership, policies, scopes, groups, organization membership, subscription plan, security level або context.== IDOR ==
Приклади scopes:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
!<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
Якщо authentication відповідає на питання “хто ти?”, то authorization відповідає на питання “що тобі дозволено?”. * Хороша authorization-модель часто непомітна користувачу, але дуже помітна команді підтримки й безпеки. Якщо backend без перевірки записує всі поля в database, користувач системи здатна сам собі підняти роль. {| class="wikitable"

Session-based authorization часто застосовується для в:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

|- | Viewer | Переглядати документи |- | Editor | Переглядати й редагувати документи |- | Admin | Керувати користувачами й налаштуваннями |}

Головна думка: authorization — це не одна перевірка “чи користувач системи увійшов”.

Якщо немає правила — заборонити.

Хороші практики Authorization

"name": "Oleh",

Складніша модель потрібна, якщо виступає як:

і документ не позначений як confidential. ! IAM policies мають бути:

Практична роль: хороша авторизація має бути не тільки безпечною, а й зрозумілою для користувача. користувач системи або сервіс має отримувати тільки ті права,

-rw-r----- user group report.txt

• multi-tenant SaaS;
• finance systems;
• healthcare;
• internal analytics;
• security-sensitive data;
• shared databases. * 403 означає, що користувач системи здатна бути відомим системі, але дія йому заборонена.== Authorization у CMS ==

Roles: ACL або Access Control List — список доступів для конкретного ресурсу. Значення Viewer:

Висновок

У CMS авторизація керує тим, хто здатна створювати, редагувати, публікувати й видаляти контент. Критично: access token — це ключ доступу. "scope": "article:read article:write",

Критично: privacy-порушення часто починаються не з хакера, а з того, що занадто багато внутрішніх користувачів мають зайвий доступ.

Критично: privilege escalation часто небезпечніша за звичайний bug, бо відкриває доступ до чужих або адміністративних дій. } дублювання правил; inconsistent policies; stale permissions; latency; distributed tracing; audit complexity; token propagation; confused deputy problem. </div> Добрі практики: return projectRepository.update(projectId, input); '''Головна перевага:''' авторизація дає можливість системі бути відкритою для багатьох користувачів, але не відкритою для всього. '''Практична роль:''' у microservices критично вирішити, де саме ухвалюється authorization decision і де воно enforced.<syntaxhighlight lang="text"> Backend має перевіряти: - Owner * email; * phone number; * address; * payment data; * medical data; * documents; * messages; * location; * logs із персональними даними; * exports; * backups.== Authorization у файлових системах == </div> Небезпечний приклад: Owner: == Ownership == == Authorization і UX == * service identity; * allowed actions; * mTLS; * service tokens; * scopes; * network policies; * workload identity; * API gateway policies; * zero trust principles. Підхід Приклад verbs: * захист даних; * контроль доступу; * менший ризик витоків; * відповідність compliance; * безпечна командна робота; * технічна підтримка ролей; * зрозуміші межі відповідальності; * менша шкода при компрометації акаунта; * auditability; * кращий UX для різних типів користувачів; * можливість enterprise-функцій; * технічна підтримка multi-tenant SaaS. Приклад: '''критично:''' головне — не де лежать правила, а чи вони послідовні, перевірені й зрозумілі.== Authorization і Subscription Plans == ACL добре підходить для: </div> Суть: "role": "editor", <div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;"> </div> <syntaxhighlight lang="text"> * відсутність ownership check; * перевірку лише login; * predictable IDs; * слабку tenant isolation; * authorization тільки на frontend; * reuse endpoints без policy. '''Практична роль:''' checklist оптимізує знайти authorization gaps до того, як їх знайде хтось інший.== Цікавий факт == Database authorization здатна включати: <div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;"> owner permissions; group permissions; read/write/execute; ACL; file ownership; directory permissions; shared folder permissions. Чи відділена authentication від authorization?</syntaxhighlight> 2FA; least privilege; audit logs; approval flows; session expiration; IP allowlist у частині сценаріїв; separate admin roles; break-glass access; monitoring. У web/API часто використовують статуси: Чи перевіряється tenant boundary? * subject; action; resource; context; attributes; policies. Якщо він витік, його потрібно вважати скомпрометованим. Authorization: Alice здатна редагувати проєкт A, але не здатна видалити проєкт B. Практична роль: permission — це маленький атом доступу, з якого будують ролі й policies.== Deny by Default == мінімальними; регулярно перевіреними; прив’язаними до ролей; audit-friendly; без wildcard permissions без потреби; розділеними між environments.== Least Privilege == Приклад тесту: IDOR або Insecure Direct Object Reference — вразливість, коли користувач системи здатна отримати доступ до чужого ресурсу, змінивши ідентифікатор. Middleware корисний для: Service-to-Service Authorization - project.read На практиці часто використовують змішаний підхід: Одна з найпоширеніших помилок у безпеці застосунків — думати, що якщо користувач системи увійшов у систему, то він уже “безпечний”. ! {| class="wikitable" Бази даних так само мають власну систему прав.== Centralized vs Decentralized Authorization == Погано: throw new ForbiddenError(); критично: application authorization і database authorization можуть доповнювати одна одну, але не треба давати застосунку database superuser без потреби. Покупець здатна бачити свої замовлення, support agent здатна переглядати звернення, finance manager здатна робити refunds, але не змінювати код товарів. - media.upload </syntaxhighlight> if (!project) { SaaS authorization має враховувати: користувач системи бачить тільки rows, де tenant_id = його tenant_id. ! Погана авторизація здатна призвести до IDOR, privilege escalation, витоку даних і небезпечного доступу до admin-функцій. * погані role checks; * IDOR; * mass assignment; * insecure admin endpoints; * неправильні JWT claims; * слабкі policies; * надмірні default permissions; * відсутність audit. '''Проста аналогія:''' RBAC — це як бейдж у компанії: посада або роль визначає, куди можна заходити. '''критично:''' authorization — це не тільки “чи можна endpoint”, а й “які поля можна змінювати”. * Документація щодо secure API design, policy engines, zero trust і security testing. * повторного використання checks; * зменшення дублювання; * централізації базових правил; * простих role checks; * API protection. Only project owners can delete a project. - project.update == Session-Based Authorization == Приклад policy: * centralized authorization service; * local policy enforcement; * API gateway authorization; * service mesh policies; * token scopes; * shared policy library; * policy-as-code. Audit log здатна містити: </div> </div> * складних enterprise rules; * microservices; * centralized authorization; * audit; * compliance; * ABAC; * policy-as-code. | користувач системи увійшов через email і пароль |- | Authorization | Що тобі дозволено? Типові permissions: Чи виступає як negative tests? * застосунок маленький; * виступає як тільки owner і viewer; * немає sharing; * немає sensitive data; * немає enterprise customers; * немає team workspaces; * немає admin panel; * ERP-продукт ще MVP. team.member.invite '''Проста різниця:''' 401 — “спочатку увійди”, 403 — “ти увійшов, але це тобі не дозволено”. '''Критично:''' cloud role з `*:*` здатна бути зручна на старті, але дуже небезпечна в production. Access token має бути: fullAccess Чи не зберігаються зайві permissions у token?</div> </div> } <syntaxhighlight lang="text"> <syntaxhighlight lang="javascript"> </div> * хто здатна виконати дію; * з яким ресурсом; * за яких умов; * які атрибути враховуються; * які винятки існують.</div> * ризик випадкових змін; * шкоду від зламаного акаунта; * privilege escalation; * insider risk; * наслідки помилки; * доступ до чутливих даних. '''Audit logs''' фіксують важливі дії доступу. '''Mass assignment''' — проблема, коли користувач системи здатна передати зайві поля й змінити те, що не мав права змінювати. '''OAuth scopes''' — обмеження прав access token у OAuth-сценаріях.<syntaxhighlight lang="text"> * без зусиль показує “Error”; * показує кнопку, яка завжди завершується 403; * розкриває існування приватного ресурсу; * не пояснює, яку роль потрібно мати. Недоліки <syntaxhighlight lang="text"> <div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;"> Це product authorization або entitlement management. Ризики поганої авторизації </syntaxhighlight> Access control — ширше поняття, яке охоплює правила, механізми й процеси керування доступом.== Authentication vs Authorization == враховувати user/tenant у cache key; не кешувати sensitive responses без потреби; правильно ставити cache headers; invalidation після зміни permissions; перевіряти authorization перед віддачею cached data.== Privilege Escalation == кешування private response як public; показ чужих даних через shared cache; stale permissions; роль змінилася, а cache ще дає можливість доступ; CDN віддає персональні інформаційні дані; browser cache зберігає sensitive page. Коли використовувати Приклади: { Access token здатна містити або посилатися на: Error Codes: 401 і 403 Потрібно обмежувати доступ до: /invoices/1001 } '''Role''' — набір permissions, який відповідає певній функції користувача.== Authorization Middleware == * Authorization починається після authentication, а не замість неї.</div> == Authorization і Observability == Audit logs важливі для: == Типові помилки початківців == tenant id; organization membership; workspace role; resource ownership; cross-tenant isolation; admin boundaries; billing permissions; invitation rules. Практична роль: така модель проста для пояснення й достатня для багатьох командних застосунків. Краще: Якщо користувач системи не має доступу до invoice `1002`, backend має повернути заборону, навіть якщо ID існує. "tenant_id": "org_456" У microservices або distributed systems сервіси так само мають авторизуватися між собою. Цей підхід особливо важливий для: користувач системи із organization A не здатна отримати доступ до project organization B, навіть якщо знає ID project. * Матеріали щодо OWASP access control risks, IDOR, privilege escalation і least privilege. через критично: centralized policy engine користувачі можуть узгодити правила, але створює залежність, яку потрібно добре тестувати й моніторити. * RBAC простіший для пояснення людям, а ABAC гнучкіший для складних правил.== Role == Editor не здатна змінити billing settings. * перевірку ownership; backend authorization; least privilege; tests; audit для важливих дій. Див. так само користувач системи виступає як власником invoice; користувач системи має спеціальний permission для перегляду всіх invoices. JWT claims — твердження всередині JSON Web Token, які можуть містити інформацію про користувача або права. Приклад ідеї: Row-Level Security Multi-Tenant Authorization Deny by default — правило, за яким доступ заборонено, якщо немає явного дозволу. Небезпечною виступає як не простота, а відсутність перевірок. * Практики authentication і authorization у web applications. Після цього кожна важлива дія все одно має перевірятися окремо. Але frontend authorization не виступає як достатнім захистом. Приклад правила: Для admin-доступу корисні: як приклад, користувач системи здатна бути справжнім власником акаунта, але це не означає, що він має право бачити чужий invoice, видаляти чужий проєкт або відкривати admin panel. GET /api/projects/123 } У Kubernetes авторизація часто функціонує через RBAC. Authorization і caching потрібно поєднувати обережно. Підказка: найкраща перевірка authorization-моделі — спробувати описати її простими реченнями: “Хто здатна що робити з яким ресурсом?” критично: навіть якщо ID invoice передано в URL, backend має перевірити, чи має користувач системи доступ до цього invoice.</syntaxhighlight> Ownership — модель, де доступ залежить від власника ресурсу. {| class="wikitable" POST /api/projects/123/invite - Alice: read, write '''Policy''' — правило або набір правил авторизації. Роль async function updateProject(user: User, projectId: string, input: UpdateProjectInput) { </div> * current user; * action; * target resource; * ownership; * role; * permissions; * tenant; * scopes; * policy; * business rules.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;"> <syntaxhighlight lang="typescript"> <div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;"> DELETE /api/projects/123 <div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;"> == Backend Authorization == '''Критично:''' API не має покладатися на те, що frontend “не покаже кнопку”. '''критично:''' JWT потрібно перевіряти: signature, expiration, issuer, audience і claims. * users; * roles; * grants; * schemas; * table permissions; * row-level security; * column permissions; * views; * stored procedure permissions.== Policy Engine == Policy engine корисний для: <div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;"> == Приклад checklist для Authorization == == ABAC == Attributes можуть належати: '''Основна ідея:''' authorization — це не вхід у систему, а перевірка прав після входу: чи здатна саме цей користувач системи зробити саме цю дію з саме цим ресурсом. Її потрібно захищати сильніше, ніж звичайний user dashboard.== Цікаві факти про Authorization == == Коли потрібна складна authorization-модель == але не здатна змінювати user role. сторінок; API endpoints; файлів; документів; баз даних; адміністративних функцій; billing; reports; user profiles; організацій; команд; проєктів; записів; налаштувань; internal tools; cloud resources; microservices. файлів; документів; shared folders; collaboration tools; object storage; granular sharing; ресурсів, де доступ налаштовується окремо.</syntaxhighlight> API Authorization Permissions: Практична роль: CMS authorization дає можливість редактору писати статті, але не обов’язково змінювати системні конфігурація. Практична порада: складність авторизації має рости разом із реальними потребами продукту, а не з фантазіями про майбутні enterprise-функції. Назва `401 Unauthorized` історично трохи плутає, бо фактично часто означає “не authenticated”. Вона відрізняється від authentication: спочатку платформа встановлює особу користувача, а потім перевіряє його права. * Audit logs часто стають єдиним способом зрозуміти, хто отримав доступ і що зробив. canDoStuff </syntaxhighlight> repeated denied requests; access to sensitive resources; admin role changes; failed policy checks; unusual exports; cross-tenant access attempts; sudden permission changes; token misuse; service account anomalies.</syntaxhighlight> Frontend Authorization Приклади claims: Чи перевіряються JWT signature, exp, iss і aud? Кожен endpoint має перевіряти: Document 123: == OAuth Scopes == Чи перевіряється ownership? Authorization-події потрібно спостерігати. Поширені помилки: <div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;"> Потрібно перевіряти: ! '''Least privilege''' — принцип мінімально необхідних прав.<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;"> - Admin throw new NotFoundError(); API; admin panels; cloud IAM; internal tools; database permissions; file access; enterprise systems. Приховати кнопку на frontend недостатньо. Добрий UX:	REVOKE DELETE ON invoices FROM reporting_user; Owner здатна керувати billing і users, Admin здатна запрошувати учасників, Editor здатна редагувати контент, Viewer здатна тільки переглядати. Поняття Permission — конкретний дозвіл на дію. Viewer не здатна створити project. Питання - project.delete
401 Unauthorized	користувач системи не authenticated	Немає token або session недійсна
403 Forbidden	користувач системи authenticated, але не має прав	Немає permission на дію

} Приклади причин: критично: middleware здатна перевірити permission, але не завжди знає, чи користувач системи має доступ саме до конкретного project або document. Небезпека: найтиповіша помилка — перевірити “користувач системи увійшов” і забути перевірити “цей ресурс справді його”.== Authorization у Service Layer ==

Тематичні мітки

Editor:

Authorization і Feature Flags

if (!canUpdateProject(currentUser, project)) { </syntaxhighlight>

І повертати:

Хороша authorization-модель використовує least privilege, deny by default, backend checks, resource-level validation, tenant isolation, audit logs і тести заборонених сценаріїв. * draft.create;

• article.edit;
• article.publish;
• article.delete;
• media.upload;
• comment.moderate;
• user.manage;
• settings.update. * бізнес-застосунків;
• admin panels;
• SaaS;
• CMS;
• CRM;
• enterprise systems;
• командних workspace;
• простих і середніх моделей доступу. критично: роль має відповідати реальній відповідальності людини, а не бути випадковим набором прав. Рекомендовано:

Практична роль: authorization — це практична реалізація access control у застосунку або системі. * дозволені дії;

• заборонені дії;
• доступ до чужих ресурсів;
• tenant isolation;
• role boundaries;
• field-level permissions;
• admin-only endpoints;
• expired tokens;
• missing scopes;
• changed permissions;
• deleted users;
• edge cases. Погана авторизація здатна призвести до:

project.settings.update Admin здатна запросити member. Практична роль: backend authorization — це дверний замок, а frontend authorization — табличка на дверях.== Приклад ownership check ==

Загальний SEO-опис

• compute;
• storage;
• databases;
• secrets;
• logs;
• networks;
• Kubernetes;
• serverless functions;
• billing;
• monitoring;
• deployment pipelines.

• хто здатна отримати доступ;
• до чого саме;
• які дії дозволені;
• за яких умов;
• хто надав доступ;
• як доступ відкликати;
• як перевірити історію доступів. Role: Editor

</syntaxhighlight>

Authorization і Caching

• vertical privilege escalation — звичайний користувач системи отримує admin-права;
• horizontal privilege escalation — користувач системи отримує доступ до даних іншого користувача такого ж рівня. Authorization відповідає:

IDOR часто виникає через: Least privilege зменшує: - Admins: manage

Корисні сигнали:

Authorization і Privacy

Чи виступає як process для відкликання доступу? Приклад:

Access control відповідає на питання:

Access Token

критично: frontend-перевірки потрібні для зручності, але справжня безпека має бути на backend. * Free plan — 1 project;

• Pro plan — unlimited projects;
• Enterprise plan — audit logs і SSO;
• Basic plan — no export;
• Team plan — role management. - project.read

</syntaxhighlight>

У multi-tenant systems одна платформа обслуговує багато організацій або клієнтів. Потрібні негативні тести: “користувач системи не повинен мати доступ”. Дозволи - project.update

return invoice.userId === user.id || user.permissions.includes("invoice.view_all");

Authentication: Alice успішно увійшла в систему. Приклад:

Приклади сценаріїв використання

Небезпека: authorization-помилка здатна бути тихою: платформа не падає, але показує інформаційні дані не тій людині. Критично: у multi-tenant системі кожен запит до resource має перевіряти tenant boundary.

Authorization і Audit Logs

Kubernetes RBAC має:

Практична роль: session-based підхід зручний, коли сервер контролює стан входу користувача.

Project members can view project tasks. Scopes допомагають third-party applications отримувати не весь доступ, а тільки потрібний набір прав. Frontend authorization зазвичай відповідає за UX: Чи всі protected endpoints перевіряють access? * Least privilege — один із найважливіших принципів безпеки. - Viewer

• Role;
• ClusterRole;
• RoleBinding;
• ClusterRoleBinding;
• ServiceAccount;
• verbs;
• resources;
• namespaces. function canViewInvoice(user: User, invoice: Invoice): boolean {

Але навіть у простій моделі потрібно мати:

<syntaxhighlight lang="text">

'''критично:''' кеш здатна випадково обійти authorization, якщо його неправильно спроєктувати.<syntaxhighlight lang="text">

* хто виконав дію;
* яку дію;
* над яким resource;
* коли;
* з якої IP або device;
* чи була дія дозволена;
* що змінилося;
* request id;
* admin context;
* reason або ticket у enterprise-сценаріях.<syntaxhighlight lang="text">

</syntaxhighlight>

Чи функціонує deny by default? * session user id;

• roles;
• permissions;
• organization membership;
• CSRF protection;
• session expiration;
• device/session state. ! * IDOR часто виглядає як звичайний endpoint із параметром ID.== Admin Authorization ==

Погано: !== Database Authorization ==

- users.manage

Перевага: хороша авторизація дає можливість давати людям рівно той доступ, який їм потрібен, і не більше. !

- content.update Практична роль: deny by default робить систему безпечнішою при помилках конфігурації. Авторизація потрібна майже в кожному застосунку, де виступає як акаунти, ролі, приватні інформаційні дані, API, адміністративні панелі, платежі, документи, файли, команди, організації або різні рівні доступу. * У SaaS authorization часто складніша за authentication. Приклад:

• get;
• list;
• watch;
• create;
• update;
• patch;
• delete. Краще:

Ownership часто застосовується для для: Цей приклад показує два варіанти доступу: </syntaxhighlight>

!

Практична роль: service layer бачить і користувача, і ресурс, тому здатна ухвалити точніше authorization-рішення. критично: у SaaS недостатньо ролі “admin”.

• security;
• compliance;
• incident response;
• debugging;
• accountability;
• forensic analysis.

Приклад небезпечної помилки: критично: feature flag не повинен замінювати security-critical authorization check. У microservices authorization здатна бути складнішою, бо рішення для бізнесу розподілені між сервісами. Він здатна отримувати: Billing service здатна читати user profile,

Джерела

користувач системи здатна редагувати profile, якщо profile.user_id == current_user.id.=== Інтернет-магазин === </syntaxhighlight>

SaaS-застосунки часто мають складну модель доступу. } Billing admins can update payment methods. |- | Centralized | Єдине місце правил, простіший audit | здатна стати bottleneck або single point of failure |- | Decentralized | Сервіси автономні, менше latency | Ризик різних правил у різних місцях |}

користувач системи здатна переглядати документ,

• спільні policies;
• local enforcement;
• centralized identity;
• audit;
• shared libraries;
• gateway checks. Authorization напряму пов’язана з privacy, бо визначає, хто здатна бачити персональні інформаційні дані. GRANT SELECT ON invoices TO reporting_user;

adminPower

критично: якщо запит прийшов “із внутрішньої мережі”, це ще не означає, що йому можна довіряти без перевірки. Чи зрозуміла permission model команді? - users.manage

if (!canUpdateProject(user, project)) {

У SaaS доступ здатна залежати від тарифу. - project.create

• видалення користувачів;
• зміна ролей;
• refunds;
• перегляд приватних даних;
• export data;
• system settings;
• impersonation;
• moderation;
• billing;
• security logs.

  ABAC гнучкіший за RBAC, але складніший.== Authorization Testing ==
  Ризики:
  
  '''Access token''' — токен, який клієнт ERP використовує для доступу до protected resource. Основні конкурентні переваги:
  <div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
  <syntaxhighlight lang="text">
  Приклад:
  Permissions:
  
  </div>
  </div>
  <div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
  </div>
  
  </div>
  </div>
  

Mass Assignment

Практична роль: ACL дає можливість керувати доступом до конкретного об’єкта, а не лише через глобальні ролі.

=== Cloud infrastructure ===

deny

- article.publish

</div>

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
якщо department користувача збігається з department документа
Типові рівні:
'''Практична роль:''' OAuth scopes — це спосіб сказати: “цей застосунок здатна читати календар, але не здатна видаляти події”.{{SEO
|title=Authorization — авторизація, права доступу, ролі, permissions, RBAC, ABAC і безпека застосунків
|description=Authorization — Wiki-стаття про авторизацію як перевірку прав доступу після authentication. Розглянуто authentication vs authorization, permissions, roles, RBAC, ABAC, ACL, OAuth scopes, JWT claims, policy engine, least privilege, access control, API authorization, database authorization, frontend і backend перевірки, security risks, IDOR, privilege escalation, переваги, обмеження, цікаві факти і хороші практики.
|keywords=Authorization, авторизація, access control, authentication vs authorization, permissions, roles, RBAC, ABAC, ACL, OAuth scopes, JWT claims, policy engine, least privilege, privilege escalation, IDOR, API authorization, backend authorization, frontend authorization, access token, security, application security
|alternativeTo=доступ без перевірки прав; hardcoded admin checks; одна роль admin для всіх; перевірка доступу лише на frontend; shared passwords; ручне керування доступом без audit; відкриті API без permissions; надмірні права користувачів; security by obscurity; хаотичні rules без policy model
}}

Authorization потрібно тестувати так само серйозно, як бізнес-логіку. '''Практична роль:''' authorization здатна перевіряти не тільки роль, а й те, чи оплачена функція в поточному plan. '''Критично:''' admin panel — це концентрат ризику.<syntaxhighlight lang="text">

* tenant;
* workspace;
* subscription plan;
* seats;
* feature flags;
* team membership;
* invitations;
* sharing;
* billing permissions;
* data exports. '''Практична роль:''' authorization існує не тільки в web apps, а й на рівні операційної системи. які потрібні для його задачі.

• явно дозволяти тільки permitted fields;
• окремо перевіряти role changes;
• не довіряти client payload;
• використовувати DTO або schema validation.

Практична роль: authorization без audit logs відповідає “можна чи ні”, але не завжди оптимізує потім зрозуміти, хто що зробив.

'''критично:''' проста authorization-модель здатна бути хорошою. * Документація щодо RBAC, ABAC, ACL, OAuth scopes, JWT claims і API security. '''Найлюдяніший факт:''' хороша авторизація — це як добре організована будівля: люди швидко потрапляють туди, куди їм треба, але не блукають у чужих кабінетах. Приклади:
Приклади permissions:

Permission

- article.create

RLS корисна для:

• Матеріали з application security щодо access control. * user identity;
• scopes;
• roles;
• permissions;
• expiration;
• issuer;
• audience;
• client application;
• tenant;
• session context. Чи має цей користувач системи право використати цю функцію?<syntaxhighlight lang="json">

• Admin;
• Owner;
• Manager;
• Editor;
• Viewer;
• Member;
• Billing Admin;
• Support Agent;
• Auditor;
• Developer;
• Operator. - Editor

• `read:profile`;
• `write:profile`;
• `read:email`;
• `repo`;
• `payments:read`;
• `payments:write`;
• `calendar.events.read`;
• `calendar.events.write`. "sub": "user_123",

• traditional web apps;
• admin panels;
• CMS;
• internal tools;
• server-rendered applications.

Види:

CMS

Authorization впливає на user experience. критично: Kubernetes permissions треба давати обережно.<syntaxhighlight lang="typescript">

Multi-tenant API

<syntaxhighlight lang="text">

API authorization перевіряє доступ до endpoints і resources. Практична роль: observability оптимізує побачити не тільки помилки авторизації, а й спроби зловживання доступом.

• Authentication
• Access Control
• Application Security
• RBAC
• ABAC
• ACL
• OAuth
• JWT
• API Security
• Least Privilege
• Privilege Escalation
• IDOR
• OWASP
• Cloud IAM
• Kubernetes RBAC
• Database Security
• Row-Level Security
• Audit Log
• SaaS
• Multi-tenant Architecture
• Frontend
• Backend
• Security Testing
• Приватність даних
• Документація

Тести мають перевіряти:

• Authorization
• Авторизація
• Access Control
• Authentication vs Authorization
• Permissions
• Roles
• RBAC
• ABAC
• ACL
• OAuth Scopes
• JWT Claims
• Policy Engine
• Least Privilege
• Privilege Escalation
• IDOR
• API Authorization
• Backend Authorization
• Frontend Authorization
• Access Token
• Security
• Application Security
• Документація