2nd/10_Wiki/Topic_Programming/Coding/Security_Auth_Authz_Patterns.md

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

id	title	category	status	source_trust_level	verification_status	created_at	updated_at	tags	tech_stack	applied_in	aliases
security-auth-authz-patterns	Authentication vs Authorization 패턴	Coding	draft	B	conceptual	2026-05-09	2026-05-09	security auth authz rbac abac vibe-coding	language applicable_to TypeScript Backend		RBAC ABAC ReBAC policy permissions

Authentication vs Authorization

Authn = "누구냐" (token 발급), Authz = "뭘 할 수 있냐" (각 요청마다). 둘을 같은 코드에 섞으면 사고. Authz 는 resource-aware(이 사용자가 이 자원에 접근 가능한가) 가 핵심.

📖 핵심 개념

• 인증 (authn): 로그인, MFA, SSO. JWT / 세션.
• 인가 (authz): 권한 체크. 매 요청.
• 모델:
  • RBAC: role → permission. "admin can edit anything".
  • ABAC: 속성 기반. "user.dept === resource.dept".
  • ReBAC: 관계 기반 (Google Zanzibar). "user owns / shares / member of".
  • 대부분 RBAC + 일부 ABAC 조합.

💻 코드 패턴

인증 미들웨어

async function authenticate(req: Request): Promise<User> {
  const auth = req.header('authorization');
  if (!auth?.startsWith('Bearer ')) throw new UnauthorizedError();
  const token = auth.slice(7);
  const payload = jwt.verify(token, env.JWT_SECRET);
  return await db.users.find(payload.sub) ?? throw new UnauthorizedError();
}

app.use(async (req, res, next) => {
  try { req.user = await authenticate(req); next(); }
  catch (e) { res.status(401).json({ error: 'unauthorized' }); }
});

Authz — 자원 단위 (resource-aware)

async function canEditOrder(user: User, orderId: string): Promise<boolean> {
  const order = await db.orders.find(orderId);
  if (!order) return false;
  if (user.role === 'admin') return true;
  if (order.userId === user.id) return true;
  return false;
}

app.put('/api/orders/:id', async (req, res) => {
  if (!await canEditOrder(req.user, req.params.id)) {
    return res.status(403).json({ error: 'forbidden' });
  }
  // ...
});

Policy 패턴 — 별도 모듈

// policies/order.ts
export const OrderPolicy = {
  read: (user: User, order: Order) => user.id === order.userId || user.role === 'admin',
  edit: (user: User, order: Order) => user.id === order.userId && order.status === 'pending',
  delete: (user: User, order: Order) => user.role === 'admin',
};

// 사용
if (!OrderPolicy.edit(req.user, order)) return res.status(403).end();

Casl / oso — 라이브러리

import { AbilityBuilder, createMongoAbility } from '@casl/ability';

function defineAbility(user: User) {
  const { can, build } = new AbilityBuilder(createMongoAbility);
  can('read', 'Order'); // 모든 사용자
  can('manage', 'Order', { userId: user.id }); // 본인 거
  if (user.role === 'admin') can('manage', 'all');
  return build();
}

const ability = defineAbility(req.user);
if (!ability.can('update', order)) return res.status(403).end();

Open Policy Agent (OPA) — 정책 외부화

# policy.rego
allow {
  input.user.role == "admin"
}
allow {
  input.action == "read"
  input.user.id == input.resource.owner_id
}

복잡한 정책은 OPA 같은 정책 엔진. 코드와 분리, 감사 가능.

🤔 의사결정 기준

복잡도	도구
2-3 role, 단순 CRUD	role check 인라인
자원 단위 권한 (본인 / admin)	Policy 함수
다양한 조건 (시간, 부서, 단계)	Casl / oso / OPA
Multi-tenant + 공유	ReBAC (SpiceDB / Cerbos)
외부 API 호출 권한	OAuth scopes

❌ 안티패턴

• 인증 = 인가 가정: "로그인됨 = 모두 가능". resource-aware authz 필수.
• role check 만: "admin 이면 다 OK". multi-tenant / 사용자 데이터 모두 노출 위험.
• client-side authz: 메뉴 숨겨도 API 직접 호출 가능. 항상 서버.
• policy 가 코드 곳곳에: 일관성 없음. 한 모듈에 모음.
• 권한 거부 시 404 vs 403 일관성 없음: 404 면 자원 존재 여부 누설 안 됨. 정책에 따라.
• owner check 안 함: /api/orders/:id 가 본인 거인지 확인 없이 반환. IDOR 사고.
• RBAC 만 + 동적 조건 안 됨: "결제 완료 전엔 수정 가능, 후엔 admin 만" 같은 ABAC 필요.

🤖 LLM 활용 힌트

• "인증 vs 인가 분리. 매 mutation endpoint 에 resource-aware check" 강제.
• Policy 모듈 패턴 권장.

🔗 관련 문서

• Web_JWT_Patterns
• Security_CSRF_Patterns
• Security_Input_Validation