📌 OAuth란?

OAuth는 애플리케이션이 특정 시스템의 보호된 리소스에 접근하기 위해, 사용자 인증(Authentication)을 통해 사용자의 리소스 접근 권한(Authorization)을 위임받을 수 있는 표준 프로토콜이다.

간단히 말해, OAuth는 인증 표준이다. OAuth는 인증을 위한 오픈 스탠더드 프로토콜로, 사용자가 Facebook이나 트위터 같은 인터넷 서비스의 기능을 다른 애플리케이션에서도 사용할 수 있게 한 것이다.

👉 개발자 입장에서 보자면, 우리의 서비스가 우리 서비스를 이용하는 유저의 타사 플랫폼 정보에 접근하기 위해서 권한을 타사 플랫폼으로부터 위임받는 것이다.

OAuth의 Auth는 Authentication(인증) 뿐만 아니라 Authorization(허가)의 의미도 포함한다. 그렇기 때문에 OAuth 인증을 진행할 때 해당 서비스 제공자는 '제3자가 리소스[어떤 정보나 서비스]에 사용자의 권한으로 접근하려 하는데 허용하겠느냐'라는 안내 메시지를 보여주는 것이다.

인증과 인가

• Authentication(인증) : 해당 사용자가 자신이 주장하는 사람인지 확인하는 것으로, 식별(identify)과 연관된 개념이다.
• Authorization(허가) : 해당 사용자에게 리소스에 접근할 수 있는 권한을 부여하는 것으로, 접근(access)과 연관된 개념이다.

---

📌 OAuth의 등장과 발전

OAuth가 사용되기 전에는 인증 방식의 표준이 없었기 때문에 기존의 기본 인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조이다.

기본 인증이 아니어도, 다른 애플리케이션에 사용자의 아이디와 암호가 노출되지 않도록 하면서 API 접근 위임(API Access Delegation)이 가능한 여러 인증 방법이 있었다. Google과 Yahoo!, Amazon 등에서 각각의 인증 방식을 제작해서 사용했는데, 예를 들면 Google의 AuthSub, Yahoo!의 BBAuth이 있다.

하지만 이 방식은 표준화가 되어있지 않기 때문에 구글과 연동하는 서비스를 만들기 위해서는 AuthSub, 야후와 연동하기 위해서는 BBAuth에 맞춰 개별적으로 개발하고 유지보수해야 한다.

이렇게 제각각이었던 인증 방식을 표준화한 인증 방식이 바로 OAuth이다.

그 시작은 2006년에 트위터의 개발자와 Ma.gnolia의 개발자가 만나 인증 방식을 논의한 때부터였다. 두 회사의 개발자들은 API 접근 위임에 대한 표준안이 없다는 것을 알았다. 그래서 2007년 4월 인터넷에 OAuth 논의체를 만든 뒤 OAuth 드래프트 제안서를 만들어 공유해 사람들의 지지를 받았고, 최종적으로 2010년에 OAuth 1.0 프로토콜 표준안이 RFC5849로 발표되었다.
( RFC: Request for comments란 미국의 국제 인터넷 표준화 기구 IETF에서 제공 및 관리하는 문서로, 인터넷 개발에 있어서 필요한 기술, 연구 결과, 절차 등을 기술해 놓은 문서이다 )

그러나 OAuth 1.0은 웹 애플리케이션이 아닌 애플리케이션에서는 사용하기 곤란하다는 단점이 있다. 또한 절차가 복잡해 OAuth 구현 라이브러리를 제작하기 어렵고, 이런저런 복잡한 절차 때문에 리소스를 제공하는 서버에게도 연산 부담이 발생한다. 이러한 단점을 개선하기 위해 등장한 것이 바로 OAuth 2.0 (RFC6749) 이다. OAuth 2.0의 가장 큰 특징인 "인증 절차가 간략하다"라는 사실도 이에서 파생된다.

---

💡이 밖에도 OAuth 1.0과 OAuth 2.0은 다른 점이 많다. 붙은 이름을 보면 비슷해 보이지만 전혀 다른(심지어 호환되지도 않는) 보안 프로토콜로 봐도 무방하다는 점이 독특하다. OAuth 1.0의 용어와 간략한 인증 과정, 그리고 OAuth 2.0과의 차이점을 알아본 뒤 OAuth 2.0에 관해 자세히 알아보자!

---

📌OAuth 1.0

OAuth를 이용해 사용자를 인증하는 과정을 OAuth Dance라고 한다. 두 명이 춤을 추듯 정확하게 정보를 주고받는 과정을 재밌게 명명한 것이다. OAuth를 이해하려면 몇 가지 용어를 먼저 알아두어야 한다.

용어

• user
  : service provider에 계정을 가지고 있으면서, consumer를 이용하려는 개인 사용자

• consumer
  : OAuth를 사용하여 service provider에게 접근해서 그 기능을 사용하려는 웹사이트 또는 애플리케이션

• service provider
  : OAuth를 통해 접근을 지원하는 웹 애플리케이션(OAuth를 사용하는 Open API를 제공하는 서비스)

• consumer secret
  : service provider에서 consumer가 자신임을 인증하기 위한 키

• request token(요청 토큰)
  : consumer가 service provider에게 접근 권한을 인증받기 위해 사용하는 값이며, 인증 후 access token으로 변환

• access token(접근 토큰)
  접근하기 위한 키를 포함한 값

OAuth Dance, OAuth 1.0 인증 과정

• Request Token의 요청과 발급
• 사용자 인증 페이지 호출
• 사용자 로그인 완료
• 사용자의 권한 요청 및 수락
• Access Token 발급
• Access Token을 이용해 서비스 정보 요청

이 과정에 따르면 Access Token을 가지게 된 Consumer는 사전에 호출이 허락된 Service Provider의 오픈 API를 호출할 수 있다. (Access Token은 아래의 OAuth 2.0과 함께 알아보자.)

그러나 앞서 언급했 듯, OAuth 1.0은 인증 절차가 복잡한 등 단점이 많아 현재는 OAuth 2.0을 아는 것이 더욱 중요하다. OAuth 2.0에서 사용하는 용어 체계는 OAuth 1.0과 차이가 있다. 둘 다 API 보안을 위한 프로토콜이지만, 목적만 같은 뿐 다른 프로토콜이라고 이해하는 것이 좋다(실제로 호환이 되지 않는다).

---

📌 OAuth 1.0 과 OAuth 2.0의 차이?

OAuth 2.0에 관해 파헤쳐 보기 전, OAuth 1.0과 OAuth 2.0의 차이를 정리해 보자.

• 토큰 관리(발급과 갱신)
  : OAuth 1.0에서는 토큰을 발급받고 갱신하는 과정이 복잡하고 어려웠으나, OAuth 2.0에서는 새로운 토큰을 쉽게 발급받고 갱신할 수 있다.

• 인증 절차 간소화
  : OAuth 1.0에서는 디지털 서명을 통해 사용자를 인증하는 반면, OAuth 2.0은 보안 토큰을 사용해 암호화는 https에 맡긴다. 따라서 복잡한 디지털 서명에 관한 로직을 요구하지 않기 때문에 구현 자체가 개발자 입장에서 쉬워진다.

• 범용성
  : OAuth 2.0 은 보다 범용적인 프로토콜로, 모바일 기기와 같은 다양한 플랫폼에서 사용할 수 있지만, OAuth 1.0은 덜 유연하여 웹 기반 애플리케이션에서만 사용된다.

• 용어 변경, Resource/Authorization Server 분리, 다양한 인증 방식
  : 주체를 칭하는 용어가 변경되었고, 서버가 분리되었고, 인증 종류가 다양화되었다. 이는 아래의 OAuth 2.0에서 각각 설명하겠다.

---

📌 OAuth 2.0

용어

초반에 언급한 '사용자', '우리의 서비스', '타사 플랫폼(구글, 페이스북, 트위터)' 등을 부르는 용어가 존재한다. 이를 먼저 정리해 보자.

• Resource Owner (User)
  : 리소스 소유자. 우리의 서비스를 이용하면서, 구글, 페이스북 등의 플랫폼에서 리소스를 소유하고 있는 사용자이다. 리소스라 하면 '구글 캘린더 정보', '페이스북 친구 목록', '네이버 블로그 포스트 작성' 등이 해당될 것이다.

• Authorization & Resource Server (Provider)
  : Authorization Server는 Resource Owner를 인증하고, Client에게 액세스 토큰을 발급해 주는 서버이다. Resource Server는 구글, 페이스북, 트위터와 같이 리소스를 가지고 있는 서버를 말한다.

• Client (Consumer)
  : Resource Server의 자원을 이용하고자 하는 서비스. 보통 우리가 개발하려는 서비스가 될 것이다.

(+) Authorization Server와 Resource Server는 공식 문서상 별개로 구분되어 있지만, 별개의 서버로 구성할지, 하나의 서버로 구성할지는 개발자가 선택하기 나름이라고 한다.

---

어플리케이션 등록

OAuth 2.0 서비스를 이용하기 전에 선행되어야 하는 작업이 있다. Client를 Resource Server에 사전 등록하는 작업이다. 이때, Redirect URI를 등록해야 하는데, 이는 사용자가 OAuth 2.0 서비스에서 인증을 마치고 (예를 들어 구글 로그인 페이지에서 로그인을 마쳤을 때) 사용자를 리디렉션시킬 위치이다.

Redirect URI

OAuth 2.0 서비스는 인증에 성공한 사용자를 사전에 등록된 Redirect URI로만 리디렉션 시킨다. 승인되지 않은 URI로 리디렉션 될 경우, 추후 설명할 Authorization Code를 중간에 탈취당할 위험성이 있기 때문이다. 일부 OAuth 2.0 서비스는 여러 Redirect URI를 등록할 수 있다.

Redirect URI는 기본적으로 보안을 위해 https만 허용된다. 단, 루프백(localhost)은 예외적으로 http가 허용된다.

Client ID, Client Secret

등록 과정을 마치면, Client ID와 Client Secret을 얻을 수 있다. 발급된 Client ID와 Client Secret은 액세스 토큰을 획득하는 데 사용된다. 이때, Client ID는 공개되어도 상관없지만, Client Secret은 절대 유출되어서는 안 된다. 이는 심각한 보안 사고로 이어질 수 있다.

---

OAuth 2.0의 동작 메커니즘

OAuth 2.0의 동작 과정의 핵심은 Access Token 에 있다. 이는 임의의 문자열 값인데, 이 문자열의 정체는 이 토큰을 발급해 준 서비스만 알 수 있다. Access Token 을 이용해, 이 토큰 값과 관련된 고객의 정보를 우리는 해당 서비스에 요청할 수 있다. 해당 서비스는 이 토큰을 검증하고, 발급된 게 맞을 경우 해당 고객의 정보를 넘겨준다.

즉, Access Token 의 존재 자체가 고객이 정보를 넘겨주는 것을 동의함의 징표라고 할 수 있다. Client가 Access Token을 (Resource) Server에게 넘겨주면 서버는 정보를 넘겨주는 아주 간단한 방식이다.

다음의 동작 과정은 이 중요한 Access Token을 어떻게 얻고 사용하는가, 정도로 이해할 수 있겠다. 하나하나 살펴보자.

1~2. 로그인 요청

Resource Owner가 Client의 '구글로 로그인하기' 등의 버튼을 클릭해 로그인을 요청한다. Client는 OAuth 프로세스를 시작하기 위해 사용자의 브라우저를 Authorization Server로 이동시켜야 한다. 이를 위해 Client는 Authorization Server가 제공하는 Authorization URL에 response_type , client_id , redirect_uri , scope 등의 매개변수를 쿼리 스트링으로 포함하여 보낸다.

예를 들어 어떤 OAuth 2.0 서비스의 Authorization URL이 https://authorization-server.com/auth 라면, 결과적으로 Client는 아래와 같은 URL을 빌드할 것 이다.

https://authorization-server.com/auth?response_type=code
&client_id=29352735982374239857
&redirect_uri=https://example-app.com/callback
&scope=create+delete

Authorization Server에게 보낼 매개변수의 값은 아래와 같다.

• response_type : 반드시 code 로 값을 설정해야 한다(인증이 성공할 경우 Authorization Code를 받게 되기 때문).
• client_id : 애플리케이션을 생성했을 때 발급받은 Client ID
• redirect_uri : 애플리케이션을 생성할 때 등록한 Redirect URI
• scope : 클라이언트가 부여받은 리소스 접근 권한

스코프란?
스코프(Scope)는 클라이언트에게 허용된 리소스의 범위를 저장하는 것이다. OAuth 2.0은 이를 통해서 유저 리소스에 대한 클라이언트의 접근 범위를 제한할 수 있다. 스코프는 엔드포인트와 1:1관계가 아니기에, 1개의 엔드포인트가 여러 개의 스코프를 가질 수 있고, 그 반대도 가능하다. 엔드포인트를 제공하는 리소스 서버는 인증 서버가 제공하는 허용 스코프에 따라 정보를 가공하여 응답해야 할 의무가 있다.

3~4. 로그인 페이지 제공, ID/PW 제공

클라이언트가 빌드한 Authorization URL로 이동한 Resource Owner는 제공된 로그인 페이지에서 ID와 PW 등을 입력하여 인증한다.

5~6. Authorization Code 발급, Redirect URI로 리디렉션

인증이 성공되었다면, Authorization Server 는 제공된 Redirect URI로 사용자를 리디렉션시킨다. 이때, Redirect URI에 Authorization Code를 포함하여 사용자를 리디렉션 시킨다.

Authorization Code란?
: Client가 Access Token을 획득하기 위해 사용하는 임시 코드이다. 이 코드는 수명이 매우 짧다. (일반적으로 1~10분)

7~8 Authorization Code와 Access Token 교환

Client는 Authorization Server에 Authorization Code를 전달하고, Access Token을 응답받는다. Client는 발급받은 Resource Owner의 Access Token을 DB에 저장한다.

Access Token은 유출되어서는 안 되기에 제3자가 가로채지 못하도록 HTTPS 연결을 통해서만 사용될 수 있다.

Authorization Code와 Access Token 교환은 token 엔드포인트에서 이루어진다. 아래는 token 엔드포인트에서 Access Token을 발급받기 위한 HTTP 요청의 예시이다.

POST /oauth/token HTTP/1.1
Host: authorization-server.com

grant_type=authorization_code
&code=xxxxxxxxxxx
&redirect_uri=https://example-app.com/redirect
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx

매개변수를 살펴보자.

• grant_type : 항상 authorization_code 로 설정되어야 한다.
• code : 발급받은 Authorization Code
• redirect_uri : Redirect URI
• client_id : Client ID
• client_secret : RFC 표준상 필수는 아니지만, Client Secret이 발급된 경우 포함하여 요청해야 한다.

9. 로그인 성공

위 과정을 성공적으로 마치면 Client는 Resource Owner에게 로그인이 성공하였음을 알린다.

10~13. Access Token으로 리소스 접근

이후 Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client에 요청한다. Client는 위 과정에서 발급받고 DB에 저장해둔 Resource Owner의 Access Token을 사용하여 제한된 리소스에 접근하고, Resource Owner에게 자사의 서비스를 제공한다.

---

OAuth 2.0 인증 방식[종류]

위의 'OAuth 2.0 동작 메커니즘'에서는 Authorization Code를 받아 인증하는 방식을 설명했다. 이는 기본적으로 지원되며 가장 많이 쓰이는 방식이나, 이와 더불어 총 6가지의 인증 방식이 있다.

• Authorization Code Grant
  : 일반적인 웹사이트에서 소셜 로그인과 같은 인증을 받을 때 가장 많이 쓰는 방식으로 기본적으로 지원하고 있는 방식이다. 'OAuth 2.0 동작 메커니즘'에서 설명한 바와 같다.

• Implicit Grant
  : Public Client인 브라우저 기반의 애플리케이션(Javascript application)이나 모바일 애플리케이션에서 바로 Resource Server에 접근하여 사용할 수 있는 방식이다.

• Resource Owner Password Credentials Grant
  : Client에 아이디/패스워드를 받아 아이디/패스워드로 직접 access token을 받아오는 방식이다. Client가 신용이 없을 때에는 사용하기에 위험하다는 단점이 있다. 클라이언트가 확실한 신용이 보장될 때 사용할 수 있는 방식이다.

• Client Credentials Grant
  : 애플리케이션이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식이다.

• Device Code Grant
  : 장치 코드 부여 유형은 브라우저가 없거나 입력이 제한된 장치에서 사용된다.

• Refresh Token Grant
  : 리프레시 토큰을 저장해두는 방식이다. 액세스 토큰을 재발급 받을 필요가 있을 때 리프레시 토큰을 사용하고, 기존의 액세스 토큰은 만료된다.

(+) in-progress 상태인 OAuth 2.1의 Grant에서는 Implicit과 Resource owner password credentials 방식을 지원하지 않을 예정이다.

---

🙌 마치며
정리해 보자면, OAuth는 '인증하고, 접근 권한을 받을 수 있는 프로토콜'이고, OAuth 2.0은 Client가 Resource Owner의 인증을 통해 Authorization Server로부터 접근 권한(Access Token)을 받아서 Resource Server에 접근하게 되는 동작 방식이다.