Admin 멤버는 제어 평면의 ID입니다. /mcp 클라이언트를 인증하는 MCP 키와는 별개입니다.
멤버 수명 주기
새 멤버는 유효한 이메일과 최소 8자 비밀번호가 필요합니다. Username은 선택 사항이며 최대 100자입니다. 생성 시 명시적인 role ID 목록을 지정하거나 모든 역할을 요청할 수 있습니다.
멤버 목록은 검색 문자열, 활성 상태, 역할로 필터링할 수 있고 페이지네이션됩니다. 2.0.2 멤버 뷰에는 계정 상태, 생성/최근 로그인 시각, 활성 세션 수, 현재 role ID/name이 표시됩니다.
Admin 멤버 작업
| 작업 | 권한 | 주요 보호 장치 |
|---|---|---|
| 멤버 생성 | /auth/user → create | email/password validation 적용 |
| 멤버 목록/검색 | /auth/user → view | status/role/search 필터 지원 |
| 멤버 역할 교체 | /auth/user → edit | 자신의 역할은 변경할 수 없음 |
| 계정 활성화 / 비활성화 | /auth/user → edit | 자신을 비활성화할 수 없음 |
| 멤버 전체 세션 폐기 | /auth/user → edit | 해당 사용자의 세션을 즉시 무효화 |
| 비밀번호 변경 요구 | /auth/user → edit | 다음 로그인에서 플래그 강제 |
| 멤버 삭제 | /auth/user → delete | 자신은 삭제할 수 없음 |
역할
역할에는 고유한 이름, 선택적 설명, permission/action selection 집합이 있습니다. Role assignment는 many-to-many 관계이므로 하나의 멤버가 여러 역할을 가질 수 있고 하나의 역할도 여러 멤버에게 할당될 수 있습니다.
내장 SuperUser 역할은 보호됩니다. 수정하거나 삭제할 수 없으며 새 역할이나 이름을 변경한 역할이 이 보호된 ID를 사용할 수도 없습니다.
역할 편집은 활성 authorization state를 바꿉니다
역할의 permission set이 변경되면 2.0.2은 해당 역할이 할당된 멤버를 찾고 security version을 증가시킨 뒤 auth runtime-state cache barrier를 통해 변경을 수행합니다. 이미 인증된 세션이 오래된 역할 권한으로 계속 동작하는 것을 막기 위한 설계입니다.
멤버에게 할당된 역할을 제거할 때도 같은 원칙이 적용됩니다.
역할을 삭제하기 전에 dependency를 확인하십시오
Role dependency endpoint는 다음을 모두 보고합니다.
- 역할에 연결된 permission/action entry
- 현재 해당 역할이 할당된 멤버
멤버가 할당된 역할을 삭제하는 작업은 기본적으로 거부됩니다. 명시적인 force=true 경로가 있지만, 영향을 받는 사용자가 해당 역할을 잃고 security state가 무효화되므로 운영자는 먼저 dependency를 확인해야 합니다.
비밀번호 및 세션 대응
멤버 관리 기능으로 다음 로그인 시 비밀번호 변경을 요구하거나 대상 멤버의 전체 세션을 폐기할 수 있습니다. 사용자는 Auth API를 통해 자신의 세션도 관리할 수 있습니다.
역할 기반 authorization 모델은 권한에서 이어서 확인할 수 있습니다.