Autorização
Permissões
Segurança
RBAC
ABAC
Controle de Acesso

Authorization and Permissions in Applications: Secure Access Control

Authorization and Permissions in Applications: Secure Access Control

Authorization defines what an authenticated user can do. While authentication confirms identity, authorization controls access to resources and actions. This guide presents templates, implementations, and best practices for building robust permissions systems.

Authentication vs Authorization

Authentication

Answer: "Who are you?" Verifies identity through credentials.

Authorization

Answer: "What can you do?". Determines permissions after identity confirmed.

Practical Example

User logs in (authentication). System checks if you can access admin panel (authorization).

Why Authorization Matters

Without proper access control, any authenticated user can access any resource. Sensitive data is exposed, destructive actions become available. Authorization protects critical data and operations.

Access Control Models

ACL (Access Control List)

List that defines who can access each resource. Simple, but doesn't scale well to complex systems.

RBAC (Role-Based Access Control)

Permissions assigned to roles, roles assigned to users. Hierarchical structure. Most common model.

ABAC (Attribute-Based Access Control)

Decisions based on attributes: user, resource, environment. Flexible but complex.

ReBAC (Relationship-Based Access Control)

Based on relationships between entities. "You can edit if you own it." Used by Zanzibar (Google).

RBAC in Details

Components

  • Users: People or systems that access.
  • Roles: Permission sets (Admin, Editor, Viewer).
  • Permissions: Allowed actions (create, read, update, delete).
  • Features: Protected objects (posts, users, settings).

Role Hierarchy

Roles can inherit from others. Admin inherits from Editor, which inherits from Viewer. Reduces duplication.

Structure Example

ScrollPermissionsScope
Admincreate, read, update, deleteAll resources
Editorcreate, read, updateContent
ViewerreadPublic content

RBAC implementation

Database

Tables for users, roles, permissions and relationships (user_roles, role_permissions).

Verification Middleware

Before action, middleware checks whether user has required permission.

Decorators/Guards

In modern frameworks, annotations that protect routes or methods.

Permission Caching

Avoid consulting the bank for each request. Cache user permissions in Token or Redis.

ABAC: Advanced Flexibility

When to Use

When RBAC is not expressive enough. Rules depend on dynamic context.

Policy Examples

  • You can edit if you are the author of the document.
  • You can access it if you are in the same department.
  • You can approve if the amount is less than your limit.

###XACML

Standard for expressing ABAC policies. XML-based, used in enterprise environments.

Resource Level Permissions

Row-Level Security

Control by registry. User only sees their own data. PostgreSQL is natively supported.

Column-Level Security

Field control. Certain fields only visible to certain roles.

Multi-Tenancy

Isolation between tenants. Each organization only accesses its data.

Operating System Permissions

iOS

Access to camera, location, photos requires explicit permission from the user. Info.plist defines descriptions.

###Android

Permissions declared in the Manifest. Dangerous permissions require runtime consent.

Good Practices

  • Order at the time of use, not upfront.
  • Explain why you need it.
  • Run gracefully if denied.

Tokens and Claims

JWT Claims

Token can contain permission claims. Server validates without consulting the bank.

Scopes in OAuth

They define which resources the token can access. read:users, write:posts.

Care

Large tokens impact performance. Balance inline claims vs consultation.

Authorization in APIs

Verification by Endpoint

Each endpoint checks specific permission before executing.

Resource Servers

API server validates tokens and authorizes based on scopes and claims.

Policy Decision Point (PDP)

Centralized service that decides authorizations. Open Policy Agent (OPA) is an example.

Implementation Patterns

Deny by Default

Deny access unless explicitly permitted. Fail safe.

Least Privilege

Grant minimum necessary. User can only what they need.

Separation of Duties

Critical tasks require multiple people. Nobody does everything alone.

Auditing and Logging

Record Decisions

Log of who tried to access what and whether it was allowed or denied.

Anomaly Detection

Suspicious patterns: many denials, after-hours access, privilege escalation.

Compliance

Regulations require an audit trail. GDPR, SOX, HIPAA.

Common Errors

Verification Only on Frontend

Backend should always check. Frontend is manipulable.

Roles Hardcoded

It makes evolution difficult. Use flexible configuration.

Excessive Permissions

For convenience, give more access than necessary. Principle of least privilege.

Lack of Testing

Poorly tested permissions create loopholes. Test access scenarios.

Tools and Libraries

Casbin

Authorization library with support for multiple models (RBAC, ABAC, ACL).

Open Policy Agent (OPA)

Policy engine. Authorization decisions as code.

Auth0 FGA

Fine-Grained Authorization. Model similar to Google's Zanzibar.

Ory Keto

Open source implementation inspired by Zanzibar.

Multi-Tenancy and Authorization

Isolation

Tenants do not access each other's data. Checking all queries.

Roles by Tenant

User can have different roles in different organizations.

Super Admin

Cross-tenant access for platform operations. Use with extreme caution.

Conclusion

Well-implemented authorization protects data and ensures that users only do what they are supposed to. Choose suitable model (RBAC for most), implement with deny by default, test thoroughly and audit access. Security is an ongoing process, not a one-time configuration.

##FAQs

1) Is RBAC sufficient for most cases? Yes. RBAC serves most applications well. ABAC is for more complex scenarios.

2) Where to store permissions? Database for source of truth. Cache (JWT claims, Redis) for performance.

3) How to deal with permission denied? Return 403 Forbidden with generic message. Do not reveal policy details.

4) Do I need a separate authorization service? For large systems, it may be worth it. For smaller apps, the integrated library is enough.

5) How to test authorization? Automated tests that check allowed and denied access by role/permission.

Also read