자원 소유자
고친 사람 github-actions[bot]
자원 소유자는 자기 자원을 남이 쓰게 할지 말지를 정하는 쪽입니다. 사진첩을 다른 앱에 읽게 허락하는 사람이 자원 소유자입니다. 접근을 남에게 맡기는 흐름에서 이 이름은 정해진 역할 하나를 가리킵니다.
쉽고 빠른 이해
자원 소유자는 자기 자원을 남이 쓰게 할지 말지를 정하는 쪽입니다. 내 캘린더를 회의 예약 앱에 읽게 해 줄지 정하는 사람이 여기 해당합니다.
이 역할이 따로 없으면 앱에 아이디와 비밀번호를 건네야 합니다. 그러면 앱이 내 계정으로 무엇이든 할 수 있습니다. 그 앱 하나만 골라 끊을 방법도 없습니다.
- 앱이 무엇을 하고 싶은지 적어 허락을 구합니다
- 자원 소유자가 그 요청을 보고 허락하거나 거절합니다
- 허락한 범위를 적은 증표가 앱에 넘어갑니다
대가는 사람이 끼어드는 단계가 생긴다는 것입니다. 허락을 묻는 화면을 띄워야 합니다. 자원 소유자가 화면을 안 읽고 누르면 넓은 범위가 그대로 통과합니다.
앱이 자기 자원만 다룰 때는 허락을 구할 상대가 없어 이 역할이 나오지 않습니다.
상세
택배 기사가 아파트 정문에서 멈춰 섭니다. 경비실이 집에 인터폰을 걸어 「올려보내도 되겠습니까」 하고 묻습니다. 집주인이 「네」 하면 방문증은 경비실이 내줍니다.
자원 소유자는 보호된 자원에 대한 접근을 승인할 수 있는 주체입니다. 허락한다는 뜻을 밝히는 것을 승인이라고 부릅니다.
자원은 시스템이 이름을 붙여 따로 가리키는 대상 하나를 말합니다. 사진 한 장, 캘린더 한 개, 계좌 잔액 한 줄이 그렇습니다.
접근을 맡길 때 나오는 네 역할
자원을 남에게 맡기는 흐름에는 넷이 함께 섭니다. 그 넷 사이를 오가는 값이 토큰입니다. 토큰은 「이만큼은 해도 된다」는 승인을 담아 건네는 값입니다.
자원 소유자가 넷 가운데 하나입니다. 클라이언트는 자원을 대신 쓰려는 쪽이고, 흔히 앱이라고 부릅니다. 인가 서버는 승인을 받아 토큰을 내줍니다. 자원 서버는 그 토큰을 보고 자원을 내주거나 막습니다.
자원 소유자가 승인을 밝히는 단계는 흐름의 앞쪽 한 번뿐입니다. 그 뒤로는 토큰이 자원 소유자를 대신해 돌아다닙니다.
sequenceDiagram
participant 자원 소유자
participant 클라이언트
participant 인가 서버
participant 자원 서버
클라이언트->>인가 서버: 이 범위를 쓰게 해 달라
인가 서버->>자원 소유자: 허락하시겠습니까
자원 소유자-->>인가 서버: 허락한다
인가 서버-->>클라이언트: 범위가 적힌 토큰
클라이언트->>자원 서버: 토큰을 들고 자원을 요청
Note over 자원 서버: 토큰의 범위 밖이면 거절한다
역할을 따로 가른 까닭
자원 소유자와 클라이언트를 한 덩이로 보면 접근을 내주는 방법이 하나뿐입니다. 자기 자격증명을 클라이언트에 넘기는 것입니다.
자격증명은 내가 나임을 증명하는 값입니다. 아이디와 비밀번호 한 벌이 흔한 꼴입니다.
비밀번호를 넘기고 나면 곤란한 것이 셋입니다.
| 비밀번호를 넘긴 뒤 | 무엇이 곤란한가 |
|---|---|
| 클라이언트가 그 값을 어딘가에 저장한다 | 클라이언트가 털리면 계정 전체가 함께 털린다 |
| 클라이언트가 할 수 있는 일에 선이 없다 | 사진만 읽히려 했는데 글도 지울 수 있다 |
| 클라이언트 하나만 끊을 수 없다 | 비밀번호를 바꿔야 하고, 그러면 다른 클라이언트도 같이 끊긴다 |
표의 셋은 뿌리가 같습니다. 허락하는 쪽과 허락받는 쪽이 같은 값을 들고 있으면 허락의 크기를 잴 방법이 없습니다.
역할을 가르면 클라이언트가 받는 것이 비밀번호에서 액세스 토큰으로 바뀝니다. 액세스 토큰은 그 토큰의 정식 이름입니다. 허락한 범위와 기한이 붙어 있습니다.
클라이언트는 그 범위 안에서만 움직입니다. 자원 소유자는 토큰 하나만 무효로 만들면 그 클라이언트를 끊을 수 있습니다.
승인이 정하는 범위와 기한
자원 소유자의 승인은 된다와 안 된다 둘 중 하나가 아닙니다. 어디까지 되는지도 같이 정합니다.
무엇까지 허락했는지를 적은 목록이 스코프입니다. 캘린더를 읽기만 할지 일정도 넣게 할지가 여기서 갈립니다. 클라이언트가 원하는 범위를 적어 요청하면, 자원 소유자는 그 가운데 일부만 골라 허락할 수도 있습니다.
기한은 토큰에 붙는 만료 시점이 맡습니다. 만료가 지나면 클라이언트는 같은 일을 더 못 합니다. 이어서 쓰려면 리프레시 토큰으로 새 토큰을 받아야 합니다. 자원 소유자가 마음을 바꾸면 만료를 기다리지 않고 승인을 거둘 수도 있습니다.
자원 소유자와 헷갈리는 이웃
자원을 들고 있는 쪽과 승인하는 쪽은 다릅니다. 내 사진이 사진 서비스의 서버에 놓여 있어도 그 사진을 누구에게 열어 줄지 정하는 쪽은 나입니다. 서버는 그 결정을 받아 지키는 쪽이라 자원 서버라고 부릅니다.
클라이언트도 자원 소유자가 아닙니다. 클라이언트는 자원 소유자를 대신해 요청하는 애플리케이션입니다. 대신한다는 말이 성립하려면 뒤에 허락해 준 쪽이 있어야 합니다.
최종 사용자와도 갈립니다. 자원 소유자가 사람이면 최종 사용자라고 부릅니다. 회사나 다른 서비스가 자원의 임자일 수도 있습니다. 승인을 밝히는 주체가 사람이 아닐 뿐 역할은 같습니다.
이 역할이 나오지 않는 흐름
클라이언트가 자기 것인 자원만 다루는 흐름도 있습니다. 그때는 허락을 구할 상대가 없어 이 역할이 아예 나타나지 않습니다. 자원 소유자라는 이름은 남의 자원을 다루는 흐름에서만 나옵니다.
관련 항목
접근 위임에 함께 서는 역할
클라이언트 · 인가 서버 · 자원 서버 · 사용자 에이전트 · 최종 사용자
승인을 실어 나르는 값
액세스 토큰 · 리프레시 토큰 · 인가 그랜트 · 스코프 · 토큰
승인 절차를 정하는 표준
OAuth 2.0 · OpenID Connect · SAML · JWT
승인 전에 거치는 신원 확인 수단
승인을 받아 접근을 판정하는 구조
인가 · 접근 제어 · 권한 · 역할 기반 접근 제어 · 속성 기반 접근 제어 · 접근 제어 목록
승인으로 열어 주는 대상
승인이 넓게 새면 생기는 보안 문제
내준 접근을 거두는 수단
토큰 취소 · 동의 화면 · 토큰 만료
다른 이름: resource owner · 리소스 오너