OAuth?

우리는 지금까지 수없이 많은 웹사이트에 가입을 해왔습니다. 모든 사이트의 계정이 동일하면 잊어버릴 일이 없겠지만, 패스워드 규칙도 다르고 중복된 아이디도 존재할 수 있기 때문에 모두 동일하게 할 수 없었을 것입니다. 회원가입을 할 때면, 한 번쯤 생각해봤을 것입니다. “모든 사이트의 계정이 다 통일됐으면 좋겠다..” 

 

SSO(Single Sign On)를 도입하면 전혀 불가능한 일은 아닙니다. 그리고 이 SSO를 구성하기 위한 방법 중 하나로 OAuth가 있습니다.

아마 많은 사이트가 OAuth의 인증 방식을 이용하기 때문에 다음과 같은 화면을 한 번쯤은 보셨을 것입니다.

우측 그림은 보호된 자원에 대한 사용 권한을 티몬에게 위임하겠냐는 일종의 "위임장 동의서"입니다.

이 글에서는 인증을 중심으로 OAuth에 대해 설명할 것이지만, OAuth는 인증 뿐 아니라 권한 기능도 표준화하여 정의한 프로토콜임을 알아두어야 합니다.

 

그렇다면 어떻게 네이버/카카오/페이스북/페이코 계정으로 티몬(타 사이트)에 로그인이 되는지, 그 인증 구조에 대해 알아보겠습니다.

OAuth가 제공하는 인증 방법은 다음 4가지가 있습니다.

• 인가코드인가 코드 승인(Authorization Code)

• 암시적 승인(Implicit)

• 자원 소유자 패스워드 승인(Resource Owner Password)

• 클라이언트 인증 정보 승인(Client Credentials)

 

 

티몬(타 사이트)에 네이버 계정으로 로그인하는 것을 가정하에, 인증 방법 4가지를 살펴보겠습니다.

[인가 코드 승인]

위 그림에서 User Agent는 브라우저, Client는 티몬, Authorization Server는 네이버입니다.

여기서 왜 티몬이 Client인지 의문을 가질 수 있습니다. 그 이유는 Authorization Server인 네이버가 OAuth 제공자이기 때문입니다. 즉 네이버에 티몬이 OAuth를 위해 접속을 시도하므로 티몬이 Client, 네이버가 Authorization Server가 됩니다.

1. 사용자가 “네이버로 로그인” 버튼을 클릭하면, 티몬에서는 네이버의 로그인 URL로 리다이렉트 시켜 네이버의 로그인 창을 띄웁니다. 

2. 사용자는 네이버의 로그인 창에 계정 정보를 입력합니다.

3. 네이버의 로그인 창에 입력한 계정 정보가 유효하면 Authorization Code를 반환합니다. (이후의 흐름은 계정 정보가 유효하다는 것을 가정합니다.)

4. 사용자는 반환받은 Authorization Code로 티몬 서버에 로그인하겠다는 요청을 보냅니다.

5. 티몬 서버는 Authorization Code, 티몬의 private key를 통해 네이버 서버로부터 Access Token을 발급받습니다. 

6. 이후, 티몬 서버는 Access Token으로 사용자의 보호된 정보에 접근할 수 있습니다. 

여기서 티몬 서버가 인증 유지 수단으로 세션을 이용하느냐, JWT를 이용하느냐에 따라 Access Token이 저장될 곳이 달라집니다.

JWT를 이용한다면 Access Token이 브라우저에 저장될 것이고, 세션을 이용한다면 티몬 서버의 세션 저장소에 SessionID와 매핑되어 저장될 것입니다. 

 

[암시적 승인]

암시적 승인은 인가 코드 승인 과정의 3,4,5 과정이 압축된 형태라고 볼 수 있습니다. 

1. 사용자가 “네이버로 로그인” 버튼을 클릭하면, 티몬에서는 네이버의 로그인 URL로 리다이렉트 시켜 네이버의 로그인 창을 띄웁니다.

2. 사용자는 네이버의 로그인 창에 계정 정보를 입력합니다.

3. 네이버의 로그인 창에 입력한 계정 정보가 유효하면 Access Token을 반환합니다. 

4. 이후 브라우저는 티몬 서버에 Access Token을 전달해줌으로써, 티몬 서버가 사용자의 보호된 정보에 접근할 수 있도록 합니다. 

 

 

[자원 소유자 패스워드 승인]

인가코드 승인 방식과 암시적 승인 방식은 사용자가 네이버에 접속해 네이버 계정을 입력했습니다. 그러나 자원 소유자 패스워드 승인은 티몬에게 네이버의 계정 정보를 건네주고, 티몬이 네이버에게 계정 정보가 유효한지 확인을 하는 방식으로 동작합니다. 따라서 네이버 계정이 티몬에게 노출되므로 이 유형은 바람직하지 않습니다. 다른 유형으로 인증할 수 없는 경우에만 사용해야 하는데, 브라우저를 사용할 수 없는 클라이언트인 경우에 이 방법을 사용합니다. 그럴 가능성이 없겠지만 예를 들어, 파워포인트에서 네이버 로그인을 할 수 있는 기능이 생긴다면 그때는 자원 소유자 패스워드 승인 방법을 이용해야 합니다.

 

 

[클라이언트 인증 정보 승인]

지금까지의 방식은 사용자의 계정 정보가 네이버 계정인지 인증하는 작업이었다면, 이 방식은 티몬이 네이버의 오픈 API를 이용할 수 있는지 인증하는 작업입니다. 예를 들어, 네이버 오픈 API 중 특정 사용자가 자주 검색하는 키워드를 알려주는 유료 API가 있다고 가정을 해봅시다. 그리고 티몬은 그 API를 사용해 티몬 서비스에 이용하려고 합니다. 네이버의 입장에서는 본인들이 API를 제공하기로 협약을 맺은 곳에만 API요청 결과를 반환해야 하므로, 협약 업체인지 확인해야 하는데, 그 과정에서 이 클라이언트 인증 정보 승인 유형을 사용합니다.