---
title: Curity — OAuth2 Scope Best Practices vs Fine-Grained Permission Naming
source_type: company-tech-blog
url: https://curity.io/resources/learn/scope-best-practices/
archive_url:
related_branches: [feature-authentication-authorization-contract]
related_projects: [ca-skeleton]
tags: [authorization, oauth2-scopes, permission-naming, resource-action, Curity, company-tech-blog]
created: 2026-06-08
last_reviewed: 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:action` colon-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]]