iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🎃

Is Your API Authorization Properly Designed?

に公開
ドメイン駆動設計
認可
権限管理
SaaS 設計
セキュリティ設計
tech

Is API Access Control Properly Designed?

Background and Overview

APIs require access control managed by users and roles.

Access control is the cornerstone of security, and design flaws directly lead to incidents. Especially in B2B systems, where granular operation control is required for each user, separation of concerns and explicit design are essential.

Neglecting this and failing to decouple permissions from behavior during the design phase makes systems highly susceptible to data leaks and unauthorized access.

Since security incidents are critical for B2B systems, mindful development is mandatory.

Examples

  • Domain Layer: Represent operational permissions as business rules within domain objects using private functions such as Document.canView(user).
  • Use Case Layer: Explicitly manage permissions by calling requirePermission(user, Action.VIEW_DOCUMENT) at the beginning of use cases.
  • Design required permissions explicitly for every endpoint.
  • Perform access control at the request stage and return early, rather than simply hiding information in the API response.

Common Pitfalls

  • Relying on hiding elements in the UI, while the API remains accessible to everyone.
  • Scattering authorization logic across multiple locations, leading to inconsistencies and oversight when changes occur.
  • Failing to document who can perform which operations, resulting in the confusion of operational feasibility within the domain and access control within the use cases, making responsibilities unclear.

FAQ

Q. Where should permission definitions be stored?

A. It is desirable to explicitly define Roles/Permissions on the server side using enums or similar structures, allowing you to grasp at a glance who can do what. For example, you can map them like val rolePermissions = mapOf(Role.ADMIN to setOf(VIEW_DOCUMENT, APPROVE_TASK, EXPORT_CSV), Role.USER to setOf(VIEW_DOCUMENT)).

Q. What if the types of permissions increase?

A. Transition to a policy-based dynamic permission design. For example, by defining class ViewDocumentPolicy : Policy<User, Document>, you can control 'who', 'against what', and 'under what conditions' an operation can be performed through conditional branching within each Policy class. However, since this approach adds complexity, it should be judged carefully.

📘 This article is part of the SaaS Design Review Checklist (2025 Edition).

Design perspective category: 🌐 API, Authorization, and Security
Level: Structure (Structure, Principles, Responsibility Organization)
Recommended readers: Design beginners / Teams currently in design phase / Reviewers

🧭 Click here to read other perspectives as well.

Discussion