OAuth 2.0
RFC 6749: The OAuth 2.0 Authorization Framework
OAuth 이전
전통적인 서버-클라이언트 인증 모델에서
클라이언트가 접근 제한된 자원(보호된 자원)에 접근할 때
자원 소유자의 신원을 통한 서버로의 인증이 요청됐다.
이에 따라,
제 3자 애플리케이션에 제한된 자원에 대한 접근을 허용하려 할 때,
자원 소유자는 제 3자에게 신원을 전달해야 했다.
그러나 이러한 방식에는 문제 또는 제한되는 부분이 있다.
- 제 3자 애플리케이션의 정보 관리 부담
- 서버에 대한 공격 표면(attack surface) 확대 (보안 위협)
- 과도한 권한 위임
- 각각의 제 3자의 접근 권한을 관리하는 것이 불편했다.
- 공급망 공격(supply-chain attack)으로 인해 고객 데이터가 유출되면,
패스워드뿐만 아니라 그것을 통해 접근 가능한 데이터도 유출된다.
요약
💡 OAuth 등장 전, 전통적인 서버-클라이언트 구조에서 제 3자 애플리케이션의 접근 제한 자원에 대한 권한을 부여하는 과정은 문제가 많았다.대표적으로 제 3자 애플리케이션의 정보 관리 부담이 막중하다는 점과
고객 측에서도 권한 관리가 불편하다는 단점이 있다.
OAuth의 등장
OAuth는 다음 두 가지 개념을 통해 문제를 해결했다.
- ‘권한 부여(Authorization) 레이어’ 추가
- Resource owner / Client 역할 분리
기존 방식은 접근 제한된 자원에 대해
반드시 Resource owner의 신원을 통해서만 접근이 가능했다.
OAuth는 자원을 요청하는 Client의 신원에 대한 권한 부여 과정을 통해 자원 접근이 이루어진다.
따라서, 재요청에 대비하여 Resource owner의 신원을 관리할 필요가 없다.
( Resource owner / Client 역할 분리 )
OAuth에서는 Access Token을 활용한다.
이는 단순히 접근 속성과 관련된 정보를 담은 문자열이다.
Access Token은
제3자 클라이언트가 Resource owner로부터 승인을 받았음이 확인되면
Authorization(권한 부여) 서버가 발급해준다.
( ‘권한 부여(Authorization) 레이어’ 추가 )
예제
| 실체(구현) | 역할(개념) |
|---|---|
| end-user | resource owner |
| a printing service | client (SP) |
| protected photos | protected resource |
| a photo-sharing service | resource server |
| the photo-sharing service | authorization server |
| the printing service delegation-specific credentials | access token |
OAuth의 명세는 HTTP을 활용한 통신을 대상으로 설계되었다.
OAuth는 구버전 1.0과 최신의 2.0이 존재한다.
프로토콜의 구현체가 1.0과 2.0 모두를 지원할 수는 있으나,
1.0과 2.0은 근본적으로 다른 프로토콜이다.
두 프로토콜은 상호 호환성을 보장하지 않는다.
요약
💡 OAuth는 다음 세 가지 개념을 통해 자원 소유자의 신원 없이 보호된 자원에 대한 요청이 이뤄진다.- ‘권한 부여(Authorization) 레이어’ 추가
- Resource owner / Client 역할 분리
- Authorization Server가 발급한 Access Token으로 Resource Server에 자원 요청
1. 역할 (Roles)
OAuth는 다음 네 가지 역할(책임)로 구분된다.
1-1. Resource owner
보호(접근 제한)된 자원에 대한 접근 권한을 부여할 수 있는 존재
1-2. Resource server
보호된 자원이 존재하는 서버
Access Token을 활용한 자원 요청을 처리한다.
기존 Resource owner의 신원 인증 및 권한 부여 과정의 대리자
1-3. Client
보호된 자원에 대한 요청을 수행하는 애플리케이션
여기서 Client라는 단어는 그 어떤 구현 방식과도 무관한 의미로 사용되고,
헷갈린다면 SP(Service Provider)라 이해해도 된다.
1-4. Authorization server
Resource owner로부터 성공적으로 인증받고, 권한 부여까지 마친 대상에 대해
접근과 관련된 내용을 담은 Access Token을 발급하는 서버
하나의 서버가 authorization server와 resource server, 두 역할을 모두 담당할 수도 있다.
하나의 authorization server에서 발행한 토큰으로 다양한 종류의 resource server에 접근할 수 있다.
두 서버 간의 상호작용은 본 명세에서 다루지 않는다.
2. 프로토콜 흐름도 (Protocol Flow)
💡 다음 방식은 Authorization Server를 중개자로 활용하는
4.1.Authorization Code Grant 방식의 구현체를 통한 설명이다.
The preferred method for the client to obtain an authorization grant
from the resource owner (depicted in steps (A) and (B)) is to use the
authorization server as an intermediary, which is illustrated in
Figure 3 inSection 4.1.
위에서 정리한 4가지 역할을 기준으로 작성된 프로토콜 흐름도이다.
2-1. 접근 권한 요청 (Authorization request)
Client(SP)는 Resource Owner를 통해 접근 권한이 부여된다.
이 과정은 일반적으로 Authorization Server의 중개를 통해 진행되나,
Resource Owner로의 직접적인 요청 또한 가능하다.
2-2. 요청 권한 승인 (권한 부여, Authorization grant)
Resource Owner가 권한을 부여하면 Authorization Grant를 반환하는데,
이는 Resource owner의 권한이 담긴 신원 정보를 지칭한다.
(뒤에서 자세히 설명 예정)
Grant Type은
상기한 1. 접근 권한 요청 (Authorization request) 방식과
Authorization 서버에서의 타입 지원 여부에 따라 결정된다.
다음 네 가지 타입 또는 Extension (Customized) Grant 타입이 존재한다.
Authorization Code Grant ★
Implicit Grant
Resource Owner Password Credentials Grant
Client Credentials Grant
2-3. Access Token 발급 요청
(Request with Authorization grant on Authorization server)
Authorization grant를 Authorization server에 전달하여 Access Token 발급을 요청한다.
2-4. Access Token 발급
Authorization server는 Client(SP) 인증과 authorization grant에 대한 검증을 진행하고,
유효하다면 Access Token을 발급한다.
2-5. Protected Resource 요청
(Request with Access Token on Resource server)
1. 접근 권한 요청 (Authorization request)
2. 요청 권한 승인 (권한 부여, Authorization grant)
에서 수행한 인증(Authentication) 과정을 반복하지 않고,
Access Token 내부 정보를 통해 인증하고,
승인된 권한에 따라 자원을 요청한다.
2-6. Protected Resource 반환
Resource server는 Access Token을 검증하고,
유효하면 자원을 반환한다.
3. Authorization Grant
💡 보호된 자원에 접근하기 위한 자원 보유자의 권한을 포함하는 **credential**로서, Client(SP)가 Access token을 얻기 위해 사용된다.- credential: subscriber(client) 식별을 위한 신원 정보를 포함한 자료 구조 a data structure that authoritatively binds an identity and additional attributes to a token possessed by a subscriber, and can be verified when presented to the verifier in an authentication transaction. The token could be an encryption key or an encrypted password that identifies the subscriber.
The token may-
be issued by the CSP,
-
generated directly by the subscriber,
-
or provided by a third party.
The token and credential may be used in subsequent authentication events.
-
참고: 2-2. 요청 권한 승인 (권한 부여, Authorization grant)
3-1. Authorization Code
Authorization Server가 Client(SP)와 Resource owner 사이에 위치하며 두 역할을 중개하는 Authorization Code Grant 방식의 redirection-based flow 구현에 활용되며,
이는 정의된 redirect_uri로의 redirection을 수행한다.
Authorization Code타입의 Grant는 Access token과 Refresh token 모두 필요하고, Client(SP)의 기밀성이 중요한 환경에서 사용된다.
이 방식을 채택하기 위해서 Client(SP)가 갖추어야 할 요건은 다음과 같다.
- Resource owner의 User-agent(일반적으로 웹 브라우저)와 통신이 가능해야 한다.
- Redirection을 통해 Authorization server로부터 들어오는 요청을 수신할 수 있어야 한다.
Client(SP; 애플리케이션)가 보호된 자원에 접근할 때,
Resource Owner는 최초 요청에 대해 인증을 요구하고,
이후로 아래 정리된 순서에 따라 차례대로 진행된다.
Obtaining Authorization
Authorization Code Grant
3-1-1. Flow의 시작: Client Request with redirect_uri
Flow의 시작은 Client(SP)가 담당한다.
Client(SP)는 Resource owner의 User-agent에게 요청을 전달하되, User-agent(ex. 웹 브라우저)가 다시 authorization server로 요청을 전달하도록 Redirection flow를 생성한다.
이 때, 이 요청에는 Client 식별자(ID), 요청 스코프, 로컬 상태와 함께 redirect_uri가 포함된다. redirect_uri는 (B) 과정에서 authorization server에서 검증을 마친 후 user-agent에게 전달되며,
(C) 과정에서 user-agent는 이를 통해 명시된 uri로의 redirect를 수행하게 된다.
3-1-2. Client 인증 및 권한 부여: User-agent > Authorization server
Authorization server는 보호된 자원에 대해 접근 요청을 보낸 Client(SP)가
실제로 접근 가능한 권한을 보유하고 있는지 검증할 필요가 있다.
Protected Resource에 대한 Client(SP)의 접근 권한은
Protected Resource의 주인인 Resource owner에 의해 부여된다.
위와 같은 권한 부여(Authorization) 결과를 Access Token으로 만들어 정해진 유효 기간동안 Resource Server로의 원활한 자원 요청이 가능하도록 만드는 것이 Authorization server의 책임이다.
하지만 Authorization server 입장에서는 먼저 Resource owner가 실제로 Protected Resource의 주인 - 보호(접근 제한)된 자원에 대해 접근 권한을 부여할 수 있는 존재인지 확인(인증)할 필요가 있다.
따라서 Resource owner에 대한 인증(Authentication) 과정이 먼저 진행된다.
이 과정은 User-agent를 통해 진행되며, IdP(Identification Provider)가 제공하는 로그인 페이지 등이 활용된다.
인증을 성공한 이후, 권한 인가(Authorization grant) 과정이 진행된다.
SSO 등으로 로그인 상태가 유지되거나 권한 부여가 성공하면 Authorization grant로 응답한다.
인증 과정 중간에 오류가 발생한다면 Authorization server는 자원 소유자에게 Error를 고지해야 하고,
전달한 uri로의 리다이렉트를 진행해서는 안 된다.
3-1-3. Client 권한 부여 완료: User-agent > Client(SP)
자원 소유자가 Client(SP)에 대해 권한 부여를 승인(response: Authorization Grant)하면,
Authorization Server는 User-agent를 다시 Client(SP)로 redirect 시킨다.
이 때, redirect_uri는 최초 request로 보낸 것이 해당된다.
이 URI는 authorization code와 최초에 Client로부터 전달된 local state가 포함되어 있다.
3-1-4. Client Access Token 요청: Client(SP) > Authorization Server
이전에 Authorization Server로부터 전달받은 Authorization Grant(본 방식에서는 Authorization Code 형식으로 구현됨)를 Authorization Server에 전달하며 Access Token을 요청한다.
Authorization Server에서는 요청 처리에 앞서 Client에 대한 인증을 진행한다.
3-1-5. Access / Refresh Token 발급
Authorization Server가 Client에 대한 인증과 Authorization Grant 유효성을 검증하고, redirection URI가 전달받은 패턴에 적합하다는 것을 확인하면, 3-1-3. Client 권한 부여 완료: User-agent > Client(SP) 단계에서와 마찬가지로 명시된 uri를 통해 Client로 redirect한다.
Wanted 페이지에서의 OAuth 적용
- Wanted 내 보호된 자원에 접근을 시도했다고 가정하자.
- Wanted(Client)에 로그인되지 않은 상태라면,
자체 로그인 페이지로 이동한다.
- 카카오 로그인을 누르면 (A) 과정이 진행된다.
- 현재 로그인된 상태가 아니므로, (B) 과정을 진행하기 위해
Kakao Authorization Server로부터 전달받은 Login Page가
User-agent(브라우저)에게 전달된다.
- Kakao의 경우, redirection 전에 유저의 확인을 받는다.
- 보이지는 않지만, (C) 과정을 통해 Wanted 웹 서버는 Kakao Authorization Server로부터 내가 사용중인 브라우저(Resource owner의 User-agent)를 거쳐 Authorization Code를 받는다.
- 처음에 요청하려고 했던 보호된 자원에 접근하기 위해,
전달받은 Authorization Code와redirect_uri로 Kakao Authorization Server에 Access Token을 (D) 과정을 통해 요청한다. - Wanted는 최초 로그인을 시도했던 페이지를
redirect_uri로 정의했다.
때문에 Kakao Authorization Server가 로그인 성공 이후, (E) 과정을 거쳐 메인 페이지로 redirect 했다.
