Authorization

Authorization або авторизація — це процес перевірки, що користувач, сервіс або система має право виконати певну дію або отримати доступ до певного ресурсу. Якщо authentication відповідає на питання “хто ти?”, то authorization відповідає на питання “що тобі дозволено?”.

Авторизація потрібна майже в кожному застосунку, де є акаунти, ролі, приватні дані, API, адміністративні панелі, платежі, документи, файли, команди, організації або різні рівні доступу.

Основна ідея: authorization — це не вхід у систему, а перевірка прав після входу: чи може саме цей користувач зробити саме цю дію з саме цим ресурсом.

Цікавий факт

Одна з найпоширеніших помилок у безпеці застосунків — думати, що якщо користувач увійшов у систему, то він уже “безпечний”. Насправді login лише підтверджує особу. Після цього кожна важлива дія все одно має перевірятися окремо.

Наприклад, користувач може бути справжнім власником акаунта, але це не означає, що він має право бачити чужий invoice, видаляти чужий проєкт або відкривати admin panel.

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

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

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

сторінок;
API endpoints;
файлів;
документів;
баз даних;
адміністративних функцій;
billing;
reports;
user profiles;
організацій;
команд;
проєктів;
записів;
налаштувань;
internal tools;
cloud resources;
microservices.

Авторизація може базуватися на ролях, permissions, attributes, ownership, policies, scopes, groups, organization membership, subscription plan, security level або context.

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

Authentication vs Authorization

Authentication і authorization часто плутають, але це різні речі.

Поняття	Питання	Приклад
Authentication	Хто ти?	Користувач увійшов через email і пароль
Authorization	Що тобі дозволено?	Користувач може редагувати тільки свої документи

Приклад:

Authentication: Alice успішно увійшла в систему.
Authorization: Alice може редагувати проєкт A, але не може видалити проєкт B.

Важливо: успішний login не означає автоматичний доступ до всіх ресурсів.

Access Control

Access control — ширше поняття, яке охоплює правила, механізми й процеси керування доступом.

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

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

Приклади дій:

read;
create;
update;
delete;
approve;
export;
invite;
publish;
deploy;
refund;
manage users.

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

Permission

Permission — конкретний дозвіл на дію.

Приклади permissions:

`user.read`;
`user.update`;
`project.create`;
`project.delete`;
`invoice.view`;
`invoice.refund`;
`settings.manage`;
`admin.access`;
`report.export`;
`billing.manage`.

Permission краще формулювати конкретно, а не занадто загально.

Погано:

canDoStuff
adminPower
fullAccess

Краще:

invoice.refund
team.member.invite
project.settings.update

Практична роль: permission — це маленький атом доступу, з якого будують ролі й policies.

Role

Role — набір permissions, який відповідає певній функції користувача.

Приклади ролей:

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

Приклад:

Role: Editor
Permissions:
- article.create
- article.update
- article.publish
- media.upload

Важливо: роль має відповідати реальній відповідальності людини, а не бути випадковим набором прав.

RBAC

RBAC або Role-Based Access Control — модель авторизації, де доступ визначається ролями.

Приклад:

Роль	Дозволи
Viewer	Переглядати документи
Editor	Переглядати й редагувати документи
Admin	Керувати користувачами й налаштуваннями

RBAC добре підходить для:

бізнес-застосунків;
admin panels;
SaaS;
CMS;
CRM;
enterprise systems;
командних workspace;
простих і середніх моделей доступу.

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

ABAC

ABAC або Attribute-Based Access Control — модель, де доступ залежить від attributes.

Attributes можуть належати:

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

Приклад правила:

Користувач може переглядати документ,
якщо department користувача збігається з department документа
і документ не позначений як confidential.

ABAC гнучкіший за RBAC, але складніший.

Важливо: ABAC корисний для складних правил, але його важче пояснювати, тестувати й audit-ити.

ACL

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

Приклад:

Document 123:
- Alice: read, write
- Bob: read
- Team Finance: read
- Admins: manage

ACL добре підходить для:

файлів;
документів;
shared folders;
collaboration tools;
object storage;
granular sharing;
ресурсів, де доступ налаштовується окремо.

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

Ownership

Ownership — модель, де доступ залежить від власника ресурсу.

Приклад:

Користувач може редагувати profile, якщо profile.user_id == current_user.id.

Ownership часто використовується для:

user profiles;
personal documents;
orders;
comments;
messages;
uploaded files;
private notes;
individual settings.

Важливо: ownership-перевірка має бути на backend. Приховати кнопку на frontend недостатньо.

Least Privilege

Least privilege — принцип мінімально необхідних прав.

Суть:

Користувач або сервіс має отримувати тільки ті права,
які потрібні для його задачі.

Least privilege зменшує:

ризик випадкових змін;
шкоду від зламаного акаунта;
privilege escalation;
insider risk;
наслідки помилки;
доступ до чутливих даних.

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

Deny by Default

Deny by default — правило, за яким доступ заборонено, якщо немає явного дозволу.

Погано:

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

Краще:

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

Цей підхід особливо важливий для:

API;
admin panels;
cloud IAM;
internal tools;
database permissions;
file access;
enterprise systems.

Практична роль: deny by default робить систему безпечнішою при помилках конфігурації.

Policy

Policy — правило або набір правил авторизації.

Policy може відповідати на питання:

хто може виконати дію;
з яким ресурсом;
за яких умов;
які атрибути враховуються;
які винятки існують.

Приклад policy:

Only project owners can delete a project.
Project members can view project tasks.
Billing admins can update payment methods.

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

Policy Engine

Policy engine — компонент, який приймає рішення про доступ.

Він може отримувати:

subject;
action;
resource;
context;
attributes;
policies.

І повертати:

allow
deny

Policy engine корисний для:

складних enterprise rules;
microservices;
centralized authorization;
audit;
compliance;
ABAC;
policy-as-code.

Важливо: centralized policy engine допомагає узгодити правила, але створює залежність, яку потрібно добре тестувати й моніторити.

OAuth Scopes

OAuth scopes — обмеження прав access token у OAuth-сценаріях.

Приклади scopes:

`read:profile`;
`write:profile`;
`read:email`;
`repo`;
`payments:read`;
`payments:write`;
`calendar.events.read`;
`calendar.events.write`.

Scopes допомагають third-party applications отримувати не весь доступ, а тільки потрібний набір прав.

Практична роль: OAuth scopes — це спосіб сказати: “цей застосунок може читати календар, але не може видаляти події”.

JWT Claims

JWT claims — твердження всередині JSON Web Token, які можуть містити інформацію про користувача або права.

Приклади claims:

`sub`;
`iss`;
`aud`;
`exp`;
`iat`;
`role`;
`scope`;
`tenant_id`;
`permissions`.

Приклад payload:

{
  "sub": "user_123",
  "role": "editor",
  "scope": "article:read article:write",
  "tenant_id": "org_456"
}

Важливо: JWT потрібно перевіряти: signature, expiration, issuer, audience і claims. Просто розпарсити token недостатньо.

Access Token

Access token — токен, який клієнт використовує для доступу до protected resource.

Access token може містити або посилатися на:

user identity;
scopes;
roles;
permissions;
expiration;
issuer;
audience;
client application;
tenant;
session context.

Access token має бути:

короткоживучим;
захищеним;
переданим через HTTPS;
перевіреним на backend;
обмеженим потрібними scopes;
відкликаним або заміненим при ризику.

Критично: access token — це ключ доступу. Якщо він витік, його потрібно вважати скомпрометованим.

Session-Based Authorization

У session-based applications користувач входить у систему, а сервер зберігає session.

Authorization може перевіряти:

session user id;
roles;
permissions;
organization membership;
CSRF protection;
session expiration;
device/session state.

Session-based authorization часто використовується в:

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

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

API Authorization

API authorization перевіряє доступ до endpoints і resources.

Приклад:

GET /api/projects/123
DELETE /api/projects/123
POST /api/projects/123/invite

Кожен endpoint має перевіряти:

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

Критично: API не має покладатися на те, що frontend “не покаже кнопку”. Зловмисник може викликати endpoint напряму.

Frontend Authorization

Frontend authorization зазвичай відповідає за UX:

приховати недоступну кнопку;
показати правильне меню;
вимкнути action;
перенаправити з недоступної сторінки;
показати повідомлення про доступ;
адаптувати navigation.

Але frontend authorization не є достатнім захистом.

Важливо: frontend-перевірки потрібні для зручності, але справжня безпека має бути на backend.

Backend Authorization

Backend authorization — головне місце перевірки доступу.

Backend має перевіряти:

current user;
action;
target resource;
ownership;
role;
permissions;
tenant;
scopes;
policy;
business rules.

Приклад:

if (!canUpdateProject(currentUser, project)) {
  throw new Error("Forbidden");
}

Практична роль: backend authorization — це дверний замок, а frontend authorization — табличка на дверях.

Database Authorization

Бази даних також мають власну систему прав.

Database authorization може включати:

users;
roles;
grants;
schemas;
table permissions;
row-level security;
column permissions;
views;
stored procedure permissions.

Приклад SQL-ідеї:

GRANT SELECT ON invoices TO reporting_user;
REVOKE DELETE ON invoices FROM reporting_user;

Важливо: application authorization і database authorization можуть доповнювати одна одну, але не треба давати застосунку database superuser без потреби.

Row-Level Security

Row-Level Security або RLS — механізм, який обмежує доступ до рядків у таблиці.

Приклад ідеї:

Користувач бачить тільки rows, де tenant_id = його tenant_id.

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

multi-tenant SaaS;
finance systems;
healthcare;
internal analytics;
security-sensitive data;
shared databases.

Практична роль: RLS переносить частину авторизації ближче до даних, а не лише до application code.

Multi-Tenant Authorization

У multi-tenant systems одна система обслуговує багато організацій або клієнтів.

Authorization має перевіряти:

tenant id;
organization membership;
workspace role;
resource ownership;
cross-tenant isolation;
admin boundaries;
billing permissions;
invitation rules.

Приклад небезпечної помилки:

Користувач із tenant A може відкрити resource tenant B через зміну ID в URL.

Критично: у multi-tenant системі кожен запит до resource має перевіряти tenant boundary.

IDOR

IDOR або Insecure Direct Object Reference — вразливість, коли користувач може отримати доступ до чужого ресурсу, змінивши ідентифікатор.

Приклад:

/invoices/1001
/invoices/1002

Якщо користувач не має доступу до invoice `1002`, backend має повернути заборону, навіть якщо ID існує.

IDOR часто виникає через:

відсутність ownership check;
перевірку лише login;
predictable IDs;
слабку tenant isolation;
authorization тільки на frontend;
reuse endpoints без policy.

Критично: IDOR — одна з найпідступніших authorization-помилок, бо endpoint може виглядати абсолютно нормальним.

Privilege Escalation

Privilege escalation — ситуація, коли користувач отримує більше прав, ніж мав.

Види:

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

Приклади причин:

погані role checks;
IDOR;
mass assignment;
insecure admin endpoints;
неправильні JWT claims;
слабкі policies;
надмірні default permissions;
відсутність audit.

Критично: privilege escalation часто небезпечніша за звичайний bug, бо відкриває доступ до чужих або адміністративних дій.

Mass Assignment

Mass assignment — проблема, коли користувач може передати зайві поля й змінити те, що не мав права змінювати.

Небезпечний приклад:

{
  "name": "Oleh",
  "role": "admin"
}

Якщо backend без перевірки записує всі поля в database, користувач може сам собі підняти роль.

Краще:

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

Важливо: authorization — це не тільки “чи можна endpoint”, а й “які поля можна змінювати”.

Admin Authorization

Admin authorization має бути особливо обережною.

Admin actions можуть включати:

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

Для admin-доступу корисні:

2FA;
least privilege;
audit logs;
approval flows;
session expiration;
IP allowlist у частині сценаріїв;
separate admin roles;
break-glass access;
monitoring.

Критично: admin panel — це концентрат ризику. Її потрібно захищати сильніше, ніж звичайний user dashboard.

Service-to-Service Authorization

У microservices або distributed systems сервіси також мають авторизуватися між собою.

Потрібно перевіряти:

service identity;
allowed actions;
mTLS;
service tokens;
scopes;
network policies;
workload identity;
API gateway policies;
zero trust principles.

Приклад:

Billing service може читати user profile,
але не може змінювати user role.

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

Authorization у Microservices

У microservices authorization може бути складнішою, бо рішення розподілені між сервісами.

Підходи:

centralized authorization service;
local policy enforcement;
API gateway authorization;
service mesh policies;
token scopes;
shared policy library;
policy-as-code.

Проблеми:

дублювання правил;
inconsistent policies;
stale permissions;
latency;
distributed tracing;
audit complexity;
token propagation;
confused deputy problem.

Практична роль: у microservices важливо вирішити, де саме ухвалюється authorization decision і де воно enforced.

Authorization у SaaS

SaaS-застосунки часто мають складну модель доступу.

Типові рівні:

system admin;
organization owner;
workspace admin;
project manager;
member;
guest;
billing admin;
read-only auditor.

SaaS authorization має враховувати:

tenant;
workspace;
subscription plan;
seats;
feature flags;
team membership;
invitations;
sharing;
billing permissions;
data exports.

Важливо: у SaaS недостатньо ролі “admin”. Часто потрібні окремі ролі для billing, users, security, content і integrations.

Authorization у CMS

У CMS авторизація керує тим, хто може створювати, редагувати, публікувати й видаляти контент.

Типові permissions:

draft.create;
article.edit;
article.publish;
article.delete;
media.upload;
comment.moderate;
user.manage;
settings.update.

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

Authorization у Cloud IAM

У cloud platforms authorization часто реалізується через IAM.

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

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

IAM policies мають бути:

мінімальними;
регулярно перевіреними;
прив’язаними до ролей;
audit-friendly;
без wildcard permissions без потреби;
розділеними між environments.

Критично: cloud role з `*:*` може бути зручна на старті, але дуже небезпечна в production.

Authorization у Kubernetes

У Kubernetes авторизація часто працює через RBAC.

Kubernetes RBAC має:

Role;
ClusterRole;
RoleBinding;
ClusterRoleBinding;
ServiceAccount;
verbs;
resources;
namespaces.

Приклад verbs:

get;
list;
watch;
create;
update;
patch;
delete.

Важливо: Kubernetes permissions треба давати обережно. ServiceAccount із зайвими правами може стати шляхом до компрометації кластера.

Authorization у файлових системах

Файлові системи теж мають authorization.

Приклади:

owner permissions;
group permissions;
read/write/execute;
ACL;
file ownership;
directory permissions;
shared folder permissions.

Unix-приклад:

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

Це означає:

owner може читати й писати;
group може читати;
others не мають доступу.

Практична роль: authorization існує не тільки в web apps, а й на рівні операційної системи.

Authorization і Audit Logs

Audit logs фіксують важливі дії доступу.

Audit log може містити:

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

Audit logs важливі для:

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

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

Authorization і Privacy

Authorization напряму пов’язана з privacy, бо визначає, хто може бачити персональні дані.

Потрібно обмежувати доступ до:

email;
phone number;
address;
payment data;
medical data;
documents;
messages;
location;
logs із персональними даними;
exports;
backups.

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

Authorization і Caching

Authorization і caching потрібно поєднувати обережно.

Ризики:

кешування private response як public;
показ чужих даних через shared cache;
stale permissions;
роль змінилася, а cache ще дозволяє доступ;
CDN віддає персональні дані;
browser cache зберігає sensitive page.

Добрі практики:

враховувати user/tenant у cache key;
не кешувати sensitive responses без потреби;
правильно ставити cache headers;
invalidation після зміни permissions;
перевіряти authorization перед віддачею cached data.

Важливо: кеш може випадково обійти authorization, якщо його неправильно спроєктувати.

Authorization і Feature Flags

Feature flags можуть впливати на доступ до функцій, але не завжди є повною authorization-моделлю.

Feature flag відповідає:

Чи увімкнена функція?

Authorization відповідає:

Чи має цей користувач право використати цю функцію?

Важливо: feature flag не повинен замінювати security-critical authorization check.

Authorization і Subscription Plans

У SaaS доступ може залежати від тарифу.

Приклади:

Free plan — 1 project;
Pro plan — unlimited projects;
Enterprise plan — audit logs і SSO;
Basic plan — no export;
Team plan — role management.

Це product authorization або entitlement management.

Практична роль: authorization може перевіряти не тільки роль, а й те, чи оплачена функція в поточному plan.

Error Codes: 401 і 403

У web/API часто використовують статуси:

Код	Значення	Коли використовувати
401 Unauthorized	Користувач не authenticated	Немає token або session недійсна
403 Forbidden	Користувач authenticated, але не має прав	Немає permission на дію

Назва `401 Unauthorized` історично трохи плутає, бо фактично часто означає “не authenticated”.

Проста різниця: 401 — “спочатку увійди”, 403 — “ти увійшов, але це тобі не дозволено”.

Authorization Middleware

Authorization middleware — проміжний шар, який перевіряє доступ перед виконанням endpoint.

Приклад ідеї:

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

Middleware корисний для:

повторного використання checks;
зменшення дублювання;
централізації базових правил;
простих role checks;
API protection.

Але resource-level checks часто все одно треба робити в service layer.

Важливо: middleware може перевірити permission, але не завжди знає, чи користувач має доступ саме до конкретного project або document.

Authorization у Service Layer

Service layer часто є хорошим місцем для resource-specific authorization.

Приклад:

async function updateProject(user: User, projectId: string, input: UpdateProjectInput) {
  const project = await projectRepository.findById(projectId);

  if (!project) {
    throw new NotFoundError();
  }

  if (!canUpdateProject(user, project)) {
    throw new ForbiddenError();
  }

  return projectRepository.update(projectId, input);
}

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

Centralized vs Decentralized Authorization

Підхід	Переваги	Недоліки
Centralized	Єдине місце правил, простіший audit	Може стати bottleneck або single point of failure
Decentralized	Сервіси автономні, менше latency	Ризик різних правил у різних місцях

На практиці часто використовують змішаний підхід:

спільні policies;
local enforcement;
centralized identity;
audit;
shared libraries;
gateway checks.

Важливо: головне — не де лежать правила, а чи вони послідовні, перевірені й зрозумілі.

Authorization Testing

Authorization потрібно тестувати так само серйозно, як бізнес-логіку.

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

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

Приклад тесту:

User A не може переглянути invoice User B.
Editor не може змінити billing settings.
Viewer не може створити project.
Admin може запросити member.

Критично: authorization bug часто не видно в happy path тестах. Потрібні негативні тести: “користувач не повинен мати доступ”.

Authorization і UX

Authorization впливає на user experience.

Добрий UX:

пояснює, чому дія недоступна;
не показує зайві admin controls;
показує правильні empty states;
пропонує попросити доступ;
не розкриває зайві details;
відрізняє “немає доступу” від “ресурс не існує” там, де це безпечно.

Поганий UX:

просто показує “Error”;
показує кнопку, яка завжди завершується 403;
розкриває існування приватного ресурсу;
не пояснює, яку роль потрібно мати.

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

Authorization і Observability

Authorization-події потрібно спостерігати.

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

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.

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

Переваги хорошої авторизації

Основні переваги:

захист даних;
контроль доступу;
менший ризик витоків;
відповідність compliance;
безпечна командна робота;
підтримка ролей;
зрозуміші межі відповідальності;
менша шкода при компрометації акаунта;
auditability;
кращий UX для різних типів користувачів;
можливість enterprise-функцій;
підтримка multi-tenant SaaS.

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

Ризики поганої авторизації

Погана авторизація може призвести до:

витоку даних;
IDOR;
privilege escalation;
доступу до чужих акаунтів;
незаконних змін;
несанкціонованого export;
фінансових втрат;
порушення privacy;
втрати довіри;
compliance-проблем;
компрометації admin panel;
зламу multi-tenant isolation.

Небезпека: authorization-помилка може бути тихою: система не падає, але показує дані не тій людині.

Коли потрібна складна authorization-модель

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

багато ролей;
багато типів ресурсів;
teams або organizations;
multi-tenant architecture;
sharing;
admin panel;
billing roles;
external integrations;
compliance;
sensitive data;
field-level permissions;
approval workflows;
enterprise customers.

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

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

Простіша модель доречна, якщо:

застосунок маленький;
є тільки owner і viewer;
немає sharing;
немає sensitive data;
немає enterprise customers;
немає team workspaces;
немає admin panel;
продукт ще MVP.

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

перевірку ownership;
backend authorization;
least privilege;
tests;
audit для важливих дій.

Важливо: проста authorization-модель може бути хорошою. Небезпечною є не простота, а відсутність перевірок.

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

Рекомендовано:

відділяти 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-сценарії.

Головне правило: кожна важлива дія має відповідати на три питання: хто діє, що хоче зробити й над яким ресурсом.

Типові помилки початківців

Поширені помилки:

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

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

Цікаві факти про Authorization

Authorization починається після authentication, а не замість неї.
403 означає, що користувач може бути відомим системі, але дія йому заборонена.
Frontend authorization покращує UX, але не є security boundary.
IDOR часто виглядає як звичайний endpoint із параметром ID.
RBAC простіший для пояснення людям, а ABAC гнучкіший для складних правил.
Least privilege — один із найважливіших принципів безпеки.
У SaaS authorization часто складніша за authentication.
Зміна ролі користувача — це security-sensitive action.
Audit logs часто стають єдиним способом зрозуміти, хто отримав доступ і що зробив.
Хороша authorization-модель часто непомітна користувачу, але дуже помітна команді підтримки й безпеки.

Найлюдяніший факт: хороша авторизація — це як добре організована будівля: люди легко потрапляють туди, куди їм треба, але не блукають у чужих кабінетах.

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

SaaS workspace

Owner може керувати billing і users, Admin може запрошувати учасників, Editor може редагувати контент, Viewer може тільки переглядати.

Інтернет-магазин

Покупець може бачити свої замовлення, support agent може переглядати звернення, finance manager може робити refunds, але не змінювати код товарів.

CMS

Author може створювати drafts, Editor може редагувати чужі статті, Publisher може публікувати, Admin може керувати plugins і users.

Multi-tenant API

Користувач із organization A не може отримати доступ до project organization B, навіть якщо знає ID project.

Cloud infrastructure

CI service account може deploy-ити application, але не може читати billing або видаляти production database.

Підказка: найкраща перевірка authorization-моделі — спробувати описати її простими реченнями: “Хто може що робити з яким ресурсом?”

Приклад простої RBAC-моделі

Roles:
- Owner
- Admin
- Editor
- Viewer

Permissions:
Owner:
- organization.manage
- billing.manage
- users.manage
- project.create
- project.delete

Admin:
- users.manage
- project.create
- project.update

Editor:
- project.read
- project.update
- content.create
- content.update

Viewer:
- project.read
- content.read

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

Приклад ownership check

function canViewInvoice(user: User, invoice: Invoice): boolean {
  return invoice.userId === user.id || user.permissions.includes("invoice.view_all");
}

Цей приклад показує два варіанти доступу:

користувач є власником invoice;
користувач має спеціальний permission для перегляду всіх invoices.

Важливо: навіть якщо ID invoice передано в URL, backend має перевірити, чи має користувач доступ до цього invoice.

Приклад checklist для Authorization

Чи відділена authentication від authorization?
Чи всі protected endpoints перевіряють access?
Чи є resource-level checks?
Чи перевіряється ownership?
Чи перевіряється tenant boundary?
Чи працює deny by default?
Чи є least privilege?
Чи є negative tests?
Чи логуються admin actions?
Чи не довіряємо role з client payload?
Чи перевіряються JWT signature, exp, iss і aud?
Чи не зберігаються зайві permissions у token?
Чи є process для відкликання доступу?
Чи зрозуміла permission model команді?

Практична роль: checklist допомагає знайти authorization gaps до того, як їх знайде хтось інший.

Джерела

Матеріали з application security щодо access control.
Практики authentication і authorization у web applications.
Документація щодо RBAC, ABAC, ACL, OAuth scopes, JWT claims і API security.
Матеріали щодо OWASP access control risks, IDOR, privilege escalation і least privilege.
Практики cloud IAM, Kubernetes RBAC, database permissions, audit logging і multi-tenant SaaS security.
Документація щодо secure API design, policy engines, zero trust і security testing.

Висновок

Authorization — це ключова частина безпеки застосунків, яка визначає, хто має право виконувати конкретні дії над конкретними ресурсами. Вона відрізняється від authentication: спочатку система встановлює особу користувача, а потім перевіряє його права.

Хороша authorization-модель використовує least privilege, deny by default, backend checks, resource-level validation, tenant isolation, audit logs і тести заборонених сценаріїв. Погана авторизація може призвести до IDOR, privilege escalation, витоку даних і небезпечного доступу до admin-функцій.

Головна думка: authorization — це не одна перевірка “чи користувач увійшов”. Це система правил, яка захищає кожну важливу дію й кожен важливий ресурс.

Цікавий факт

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

Authentication vs Authorization

Access Control

Permission

Role

RBAC

ABAC

ACL

Ownership

Least Privilege

Deny by Default

Policy

Policy Engine

OAuth Scopes

JWT Claims

Access Token

Session-Based Authorization

API Authorization

Frontend Authorization

Backend Authorization

Database Authorization

Row-Level Security

Multi-Tenant Authorization

IDOR

Privilege Escalation

Mass Assignment

Admin Authorization

Service-to-Service Authorization

Authorization у Microservices

Authorization у SaaS

Authorization у CMS

Authorization у Cloud IAM

Authorization у Kubernetes

Authorization у файлових системах

Authorization і Audit Logs

Authorization і Privacy

Authorization і Caching

Authorization і Feature Flags

Authorization і Subscription Plans

Error Codes: 401 і 403

Authorization Middleware

Authorization у Service Layer

Centralized vs Decentralized Authorization

Authorization Testing

Authorization і UX

Authorization і Observability

Переваги хорошої авторизації

Ризики поганої авторизації

Коли потрібна складна authorization-модель

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

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

Типові помилки початківців

Цікаві факти про Authorization

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

SaaS workspace

Інтернет-магазин

CMS

Multi-tenant API

Cloud infrastructure

Приклад простої RBAC-моделі

Приклад ownership check

Приклад checklist для Authorization

Джерела

Висновок

Див. також

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