---
type: template
domain: product
role: Security·Privacy
status: active
last-reviewed: 2026-07-27
---

# 인증·인가·세션 정책

> 신원 확인, 자원별 권한, session lifecycle과 abuse 방어를 명시한다. 발주사 계정 체계(SSO·조직 권한)와의 연동 여부가 첫 번째 결정이다 — 자체 계정을 만들지, 발주사 신원을 신뢰할지.

## 인증

| 흐름 | 사용자·client | 검증 방식·library | MFA·복구 | 실패 응답 | rate limit |
|---|---|---|---|---|---|
| login / signup / reset / service auth |  |  |  |  |  |
| 발주사 SSO·기간계 연동 |  |  |  |  |  |

## 인가 Matrix

| 자원·행동 | anonymous | user | owner | admin·service | 확인 위치 | 거부·감사 |
|---|---|---|---|---|---|---|
|  | Deny |  |  |  | server |  |

## Session·Token

| 항목 | 결정 |
|---|---|
| token·session 종류 |  |
| 서명·검증 library·algorithm |  |
| access·refresh 수명 (발주사 세션 정책 정합) |  |
| 저장 위치·cookie flags | HttpOnly / Secure / SameSite |
| rotation·revocation |  |
| logout·분실·비밀번호 변경 |  |

## 요청 보호

| 위험 | 통제 | 적용 endpoint | 검증 |
|---|---|---|---|
| CSRF | token 또는 안전한 SameSite 정책 |  |  |
| brute force·credential stuffing | rate limit·lock·alert |  |  |
| IDOR·권한 상승 | server-side resource authorization |  |  |
| 사용자 열거 | 일관된 응답·timing |  |  |

## 완료 질문

- [ ] 모든 보호 endpoint가 명시적 인증·인가를 수행하는가?
- [ ] URL parameter와 client의 `isAdmin` 같은 주장을 권한 근거로 쓰지 않는가?
- [ ] 자체 암호·hash·token 알고리즘을 만들지 않았는가?
- [ ] session 만료·갱신·철회·동시 접속 정책이 있고 발주사 보안 정책(비밀번호 규칙·세션 시간)과 충돌하지 않는가?
- [ ] 인증 실패가 계정 존재 여부를 누설하지 않는가?
- [ ] 인가 matrix가 기능사양서의 권한 정의와 일치하는가? ([[외주 개발 산출물]])

## 승인·예외

- Security 승인자:
- 업무 권한 Owner (발주사 현업):
- 발주사 보안 담당 확인:
- 예외·만료일: