5.8 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | last_reviewed | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Curity — OAuth2 Scope Best Practices vs Fine-Grained Permission Naming | company-tech-blog | https://curity.io/resources/learn/scope-best-practices/ |
|
|
|
2026-06-08 | 2026-06-08 |
Curity — OAuth2 Scope Best Practices vs Fine-Grained Permission Naming
Layer:
raw/company-tech-blogs/— Curity (Identity Provider 전문 벤더, 독립 IdP 회사) 의 OAuth2 scope design 가이드. 공식 표준이 아니며 회사 블로그 이지만, OAuth2/OIDC 전문 벤더로서 실무 권위가 높음. feature-authentication-authorization-contract 의 permission naming convention axis 결정의 industry practice 근거.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-authentication-authorization-contract | OAuth2 scope (entry-point) 와 application-level permission (fine-grained) 의 분리 결정, resource:action naming format 의 industry practice 근거 |
출처 / Source
- 원본 URL: https://curity.io/resources/learn/scope-best-practices/
- 저자 / 조직: Curity AB (OAuth2/OIDC IdP 전문 벤더, 스웨덴)
- 발행일: 2024 (최신 revision 확인 필요)
- 마지막 확인일: 2026-06-08
- 주의: company-tech-blog — official-doc 수준의 규범력 없음.
company-case-study이 아닌engineering-blog수준으로 취급
왜 저장했는지 / Why archived
OAuth2 scope 와 internal application permission 의 관계를 명확히 해야 함. Curity 는 "scope only enables entry-point API authorization, fine-grained details use claims/permissions" 를 구분하는 실무 지침을 제공. resource:action naming 의 resource_type:access_level 패턴 참조.
핵심 인용 / Key quotes (verbatim)
[§Scopes Design — naming] "Resource Type: order, Access Level: read, Scope Value: order_read" (scope naming example using underscore)
[§Scopes Design — colon separator] "order:item" and "order:payment" represent subresources within the order domain (colon as hierarchical separator)
[§Use Claims for Fine-Grained Access Control] "Scopes only enable entry-point API authorization...finer details of authorization [should use] Claims"
[§Use Least-Privilege Scopes — hierarchical] "order:items" and "inventory:price:write" demonstrate hierarchical, action-suffixed scope design.
[§Use Least-Privilege Scopes — default] "make read-only access the default and then add a write suffix when higher privilege is needed."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| CURITY-SCOPE-C1 | OAuth2 scope 는 entry-point API authorization 만 담당하고, fine-grained authorization 은 JWT claims 을 사용해야 함 | [§Use Claims] "Scopes only enable entry-point API authorization...finer details of authorization [should use] Claims" | engineering-blog |
OAuth2 scope 와 application-level permission 의 책임 분리 결정 | 이것이 RFC 6749 등 공식 표준의 요구사항이라는 것은 아님 — Curity 의 실무 권고 |
| CURITY-SCOPE-C2 | resource:action (colon) 형식의 scope naming 이 실용적 — order:items, inventory:price:write 등 hierarchical colon-separated naming |
[§Use Least-Privilege Scopes] "order:items" and "inventory:price:write" examples | engineering-blog |
internal permission naming 에서 colon separator 선택 근거 | colon separator 가 모든 OAuth2 server 에서 안전하다는 것은 아님 — URL encoding context 별 검토 필요 |
| CURITY-SCOPE-C3 | least-privilege scope 원칙: read-only 를 default, write 는 suffix 로 명시. 일반 write 가 read 를 implies | [§Use Least-Privilege Scopes] "make read-only access the default and then add a write suffix when higher privilege is needed." | engineering-blog |
permission 설계 시 read/write 분리 방식 참조 | 반드시 read/write 이분법을 따라야 한다는 것은 아님 — domain-specific action 명이 더 명확할 수 있음 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
CURITY-SCOPE-C1: scope = entry-point, claims/permissions = fine-grained — industry 실무 관행 (Curity 기준)CURITY-SCOPE-C2:resource:actioncolon-separated format 이 OAuth2/permission naming 에서 실용적 관행
- 이 자료가 증명하지 않는 것:
- Curity 의 권고가 RFC 또는 공식 표준이라는 것
- application-internal permission 에 반드시 OAuth2 scope naming 과 동일 convention 을 따라야 한다는 것
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-skeleton 에서 Keycloak client scope 와 application-internal permission 을 동일 naming convention 으로 통일할지 별도로 분리할지
메모 / Notes
- 중요 구분: OAuth2 scope (
order:read) 는 IdP/authorization-server 관리, application-internal permission (worklog:close) 는 application code 관리 — 같은 naming 형식이더라도 다른 레이어 - Curity 의 위치: Curity 는 OAuth2/OIDC IdP 전문 벤더이므로 scope 설계 권고에 대한 실무 권위가 있지만, 공식 표준 기관은 아님
- RFC 6749 scope: OAuth2 RFC 6749 §3.3 에서 scope 는 case-sensitive string 이고 format 은 사양 외 — naming 은 구현자 재량 (IETF 표준 명시 없음)
Related / 관련
- raw/official-docs/aws-iam-google-iam-permission-naming-convention — industry IAM permission naming 비교
- raw/official-docs/owasp-authz-permission-model-abac-rbac — permission model 정당화
- raw/branch-notes/feature-authentication-authorization-contract