OAuth란?
OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. (출처: 위키백과 OAuth)
개요
OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조이다.
기본인증이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인하였다. 예를 들면 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등이 있다.
OAuth는 이렇게 제각각인 인증방식을 표준화한 인증방식이다. OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요없다. 따라서 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 된다. (출처: 위키백과 OAuth)
2012년 Oauth 2.0을 새롭게 나타났으며, OAuth 2.0 특징은 다음과 같습니다. (출처: NAVER D2)
- 웹 애플리케이션이 아닌 애플리케이션 지원 강화 (모바일 어플리케이션에서 사용 가능)
- 암호화가 필요 없음 HTTPS를 사용하고 HMAC을 사용하지 않는다. (반드시 HTTPS를 사용하기에 보안 강화)
- Siganature 단순화 정렬과 URL 인코딩이 필요 없다.
- Access Token 갱신 OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할 수 있었다. 트위터의 경우에는 Access Token을 만료시키지 않는다. OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다. (Access Token 만료기간 생김)
용어
· Resource Owner : 일반 사용자(리소스의 권한을 가진 사용자). 사용자 혹은 유저(User)라고도 합니다.
ex) A 쇼핑몰에서 SNS 계정으로 로그인 혹은 가입을 시도하려는 자
· Client : 리소스 서버에 접근을 요청하는 어플리케이션 혹은 웹 사이트. 즉, 서비스를 제공자이며 Third Party Application 라고도 합니다.
ex) A 쇼핑몰에서는 SNS 계정으로 로그인하여 쇼핑 할 수 있다. 여기서 클라이언트는 A 쇼핑몰이다.
· Authorization Server : 액세스 토큰(Access Token)을 클라이언트에게 발급해주는 서버. 인가의 주체이기도 합니다.
ex) 로그인을 통해 인증 후, 권한를 부여하는 서버(인가의 주체). 구글, 페이스북, Github 등
· Resource Server : Authorization Server가 발급한 액세스 토큰(Access Token)을 확인하고 리소스를 제공. API 서버이기도 합니다.
ex) 이름, 나이 등 아이디 관련 정보(리소스)를 제공하는 서버. 구글, 페이스북, Github 등
cf.) Authorization Server와 Resource Server를 묶어서 OAuth Provider라고도 합니다.
OAuth2.0 승인 방식(Grant Type)의 종류
· Authorization Code Grant Type
OAuth2.0 Grant Type에서 가장 잘 알려진 방식이며 중요한 보안 이점을 제공하는 방법입니다.
클라이언트가 사용자 대신 특정 리소스에 접근을 요청할 때 사용됩니다. 클라이언트는 Access Token을 발급 받기 전,
인가코드(Authorization Code)를 사용자에 의해 받게 되고, 그 인가코드(Authorization Code)를 가지고
인가 서버(Authorization Server)에 요청을 보내면 리소스에 대한 Access Token을 발급 받을 수 있습니다.
· Implicit Grant Type
Authorization Code Grant Type과 다르게, 인가코드(Authorization Code) 교환 단계 없이 Access Token을 즉시 반환받아
이를 인증에 이용하는 방식입니다.
· Resource Owner Password Credentials Grant Type
클라이언트가 암호를 사용하여 Access Token에 대한 사용자의 자격 증명을 교환하는 방식입니다.
· Client Credentials Grant Type
클라이언트가 컨텍스트 외부에서 Access Token을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식입니다.
OAuth2.0 프로세스
· Authorization Code Grant 방식의 OAuth2.0 프로세스
1. Resoruce Owner인 User가 Client를 통해서 인가(Authorization)를 시작합니다.
2. Client는 User를 Authorization Server로 포워드 해줍니다.
3. Authorization Server는 User에게 로그인창을 제공하여 User를 인증하게 됩니다.
4. User가 ID/Password를 입력하여 로그인 하면, Client가 Resource에 대한 접근 권한을 요청합니다.
5. Authorization Server는 Authorization Code를 Client에게 제공해줍니다.
6. Client는 Authorization Code로 Authorization Server에 Access Token을 요청합니다.
7. Authorization Server는 Client에게 Access Token을 발급해줍니다.
8. Access Token을 이용하여 Resource Server의 자원에 접근할 수 있게 됩니다.
9. 이후 Access Token이 만료되면 Refresh Token을 이용하여 Access Token을 재발급 받을 수 있습니다.
사실 처음에는 위 시퀀스 다이어그램으로 감이 잘 안와서, PAYCO에서 제공한 Oauth2.0 프로세스를 가져왔습니다.
PAYCO Oauth2.0 프로세스
1~5 단계는 Authorization Code 발급 요청 URL을 통해 진행할 수 있습니다.
7~8 단계는 서비스에서 callback URL 을 통해 전달받은 Authorization Code를 사용하여 Access Token 요청 API를 통해
진행할 수 있습니다.
8 단계에서 발급받은 Access Token은 서비스에서 자체적으로 저장, 관리해야 합니다.
10~11 사용자의 서비스 요청 시 회원정보가 필요하다면 Access Token을 사용해 API를 호출할 수 있습니다.
(출처: PAYCO 개발자센터) 만약 문제가 된다면 삭제하겠습니다.
참고로 위 프로세스에서
사용자는 Resoruce Owner 이며,
서비스는 Client,
PAYCO 인증 서비스는 Authorization Server,
PAYCO API 서비스는 Resource Server
입니다.
Access Token
인가 서버(Resource Server)에 자원이 필요하면, Client는 Access Token을 가지고 인가 서버(Resource Server)에 요청합니다.
이번에는 좀 더 들어가서 Access Token의 발급과 만료에 대해서 보겠습니다. 다음은 RFC에서 제공하는 Access Token 발급 과정 입니다.
The flow illustrated in Figure 2 includes the following steps:
(A) The client requests an access token by authenticating with the authorization server
and presenting an authorization grant.
(B) The authorization server authenticates the client and validates the authorization grant,
and if valid, issues an access token and a refresh token.
(C) The client makes a protected resource request to the resource server by presenting the access token.
(D) The resource server validates the access token, and if valid, serves the request.
(E) Steps (C) and (D) repeat until the access token expires. If the client knows the access token expired,
it skips to step (G); otherwise, it makes another protected resource request.
(F) Since the access token is invalid, the resource server returns an invalid token error.
(G) The client requests a new access token by authenticating with the authorization server and presenting
the refresh token. The client authentication requirements are based on the client type and on the
authorization server policies.
(H) The authorization server authenticates the client and validates the refresh token, and if valid, issues
a new access token (and, optionally, a new refresh token).
Steps (C), (D), (E), and (F) are outside the scope of this
specification, as described in Section 7.
즉, 풀어서 말하자면 다음과 같습니다.
(A)~(B)
인가코드(Authorization Code)를 가지고 인가 서버(Authorization Server)에 요청을 보내면 리소스에 대한 Access Token과 Refresh Token을 발급 받을 수 있습니다.
(C)~(F)
발급받은 Access Token을 가지고 리소스 서버에 리소스를 요청하면 Protected Resource를 받을 수 있으며, 잘못된 토큰이거나 사용기간이 만료되면 Invalid Token Error를 받습니다.
(G)~(H)
만약 Access Token의 사용기간이 만료되면, Refresh Token을 인가 서버(Authorization Server) 보내 Access Token을 재발급 받을 수 있으며 선택적으로 Refresh Token도 재발급 받을 수 있습니다.
Refresh Token
Refresh Token은 액세스 토큰이 만료될 때 Resource Owner가 인가 서버(Authorization Server)를 통해 수행해야 하는 인증, 인가 절차를 수행하지 않아도 되기 때문에 좀 더 좋은 사용자 경험을 제공할 수 있습니다.
유효기간이 짧은 Access Token의 경우 그 만큼 사용자는 로그인을 자주 해서 새롭게 토큰을 발급받아야 하므로 불편합니다. 이 것을 해결하기 위한 방법으로 나온것이 Refresh Token입니다.
처음 로그인시 Access Token과 Refresh Token은 동시에 발급되며 Refresh Token의 유효기간은 Access Token보다 더 깁니다. Access Token이 만료되었을 때 새로 발급해주는 열쇠이기도 합니다. 만약 Refresh Token의 유효기간이 만료되었다면 사용자는 다시 로그인 해야됩니다.
예를 들어, Refresh Token의 유효기간은 2주, Access Token의 유효기간은 24시간이라 하겠습니다. 사용자는 API 요청을 신나게 하다가 24시간이 지나게 되면, 가지고 있는 Access Token은 만료됩니다. 그러면 Refresh Token의 유효기간 전까지는 Access Token을 새롭게 발급받을 수 있습니다.