[보안] OAuth란? (OAuth1.0, OAuth2.0)

OAuth는 Open Authorization의 줄임말입니다. 웹개발, 특히 보안이 중요한 로그인 회원가입에 대한 개발을 하다보면 한번쯤은 보는 단어죠!.

오늘은 이 OAuth에 대해 알아보겠습니다!

---

OAuth 탄생배경

서비스를 이용하다보면 한 서비스가 다른 서비스와 연동이 되는 경우를 볼 수 있습니다. Facebook이나 트위터가 세상에 널리 퍼지게된 이유 중에 하나가 외부 서비스에서도 Facebook과 트위터의 일부 기능을 사용할 수 있게 한 것입니다. 외부 서비스와 연동되는 Facebook이나 트위터의 기능을 이용하기 위해 사용자가 반드시 Facebook이나 트위터에 로그인해야 하는 것이 아니라, 별도의 인증 절차를 거치면 다른 서비스에서 Facebook과 트위터의 기능을 이용할 수 있게 되는 것입니다.

 

이처럼 사용자가 A서비스에서 B서비스의 일부를 이용하기 위해서는, A서비스안에서 B서비스에 대한 인증이 필요합니다. OAuth 가 등장하기 전에는 충분히 아래와 같은 상황이 일어났을 수도 있습니다.

사용자: 저 A서비스님, 저 님 서비스안에서 B서비스를 이용해야되거든요 근데 저 B서비스 회원이에요.
A서비스: "그래? 그럼 B서비스에 로그인하는 아이디랑 패스워드 줘봐, 내가 대신 로그인해서 니가 B서비스이용자인지 인증해줄게!".
B서비스: "야 왜 니가 우리 사용자도 아닌데 우리 서비스 아이디랑 비밀번호를 왜 알아야돼? 나는 너 못믿어. 너 만약 나중에 해킹사고 나면 다 A서비스 니탓이야"

위는 약간 극단적인 경우이긴하지만 이러한 이유때문에 서비스간의 직접적으로 아이디와 비밀번호를 제공하지 않고 인증을 수행해야 할 필요성이 생겼습니다! 

 

이에는 여러 방법이 있을 수 있습니다. OAuth의 탄생 이전에도 Google과 Yahoo!, AOL, Amazon 등에서는 각각의 인증 방식을 제작하여 사용하고 있었습니다. 하지만 정해진 표준이 없었습니다. 2006년에 트위터의 개발자와 소셜 북마크 서비스인 Gnolia의 개발자가 만나 인증 방식을 논의하면서 이같은 API 접근 위임에 대한 표준안이 없다는 것을 알게 된 후 2007년 인터넷에 OAuth 논의체를 만든 뒤 OAuth 드래프트 제안서를 만들어 공유했습니다.

 

그리고 2010년에 OAuth 1.0 프로토콜 표준안이 RFC5849로 발표되었습니다. 이제 모두가 지킬 수 있는 표준안이 생긴것이죠.

 

정리하면 OAuth는 다른 서비스의 회원 정보를 안전하게 사용하기 위한 방법이라고 생각하면 됩니다. 여기에서 안전하게의 주체는, 회원 정보를 가지고 있는 주체, 우리의 고객입니다. 즉, 우리의 고객이 안전하게 다른 서비스의 정보를 우리 서비스에 건네주기 위한 방법이라고 볼 수 있습니다

 

**OAuth를 이용하여 사용자를 인증을 하는 과정을 OAuth Dance라고 합니다. 두 명이 춤을 추듯 정확하게 정보를 주고받는 과정을 재미있게 명명한 것이죠

---

OAuth1.0

OAuth는 표준 프로토콜인 만큼 정해진 용어가 있습니다.

• 역할
  • User: Service Provider에 계정을 가지고 있으면서, Consumer를 이용하려는 사용자
  • Service Provider: OAuth를 사용하는 Open API를 제공하는 서비스 (위 예시에서 B서비스에 해당합니다)
  • Consumer: OAuth 인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스 (위 예시에서 A서비스에 해당합니다)
• 인증 및 토큰
  • Request Token: Consumer가 Service Provider에게 접근 권한을 인증받기 위해 사용하는 값. 인증이 완료된 후에는 Access Token으로 교환
  • Access Token: 인증 후 Consumer가 Service Provider의 자원에 접근하기 위한 키를 포함한 값

아래의 그림은 OAuth1.0 방식의 대표적인 3-legged-auth 방식입니다.

OAuth1.0a: 3-legged-auth

하지만..

OAuth1.0은 구현이 복잡하고 웹이 아닌 어플리케이션에서의 지원이 부족하였습니다. HMAC을 통해 암호화를 하는 번거로운 과정을 겪습니다. 또한 인증토큰(Access Token)이 만료되지 않습니다.

 

이러한 문제점으로 인해 OAuth2.0이 등장합니다

---

OAuth2.0

숫자는 바뀌었는데..! 또 무엇이 바뀌었는지 한번 살펴보겠습니다!

 

OAuth2.0에서 크게 달라진 점

• OAuth 2.0은 더 이상 클라이언트 응용 프로그램에 암호화가 필요하지 않습니다: OAuth1.0에서는 직접 토큰이나 문자열을 암호화해서 넘겨주어야했지만, OAuth2.0은 https 통신이 필수이기 때문에 https 암호화 방식에 맡깁니다
• OAuth 2.0의인증 토큰(Access Token) 만료기간은 "짧습니다": 일반적으로 OAuth1.0에서 인증 토큰은 만료기간이 없습니다. 그래서 한번 발급받으면 평생쓸수있죠. 하지만 OAuth2.0에는 refresh token이라는 개념이 있어서 일정기간이 지나 토큰이 만료되면, refresh token을 이용해서 토큰을 새로 발급받을 수 있습니다.
• OAuth 2.0은 브라우저 외에 앱이나 기타 응용 프로그램에서도 사용가능합니다: OAuth1.0은 브라우저에서만 가능합니다.
• OAuth 2.0은 다양한 인증방식을 지원합니다: OAuth1.0은 한가지의 인증방식만 지원합니다.

 

OAuth2.0에서도 사용되는 용어를 정리해보겠습니다.

• 역할
  • Recource Owner: 서드파티 어플리케이션에 개인정보를 가지고 있으며, Client가 제공하는 서비스를 이용하려는 사용자 (Resource는 개인정보라고 생각하면 됩니다)
  • Client: 외부 서비스에 접근하는 인증 기능을 구현할 서비스입니다. (위 탄생배경 예시에서 A서비스입니다)
  • Resource Server: 사용자의 개인정보를 직접 가지고 있는 서비스 입니다 (위 탄생배경 예시에서 B서비스입니다)
  • Authorization Server: 직접 권한을 부여하고, Token을 인증하는 서버입니다. (이부분에서 OAuth1.0과 달라집니다. 이부분도 분명 B서비스와 동일한 Scope에 있지만, 실질적인 B서비스를 이용하는 서버와 B서비스를 위해 인증만을 수행하는 B서비스측의 별도 서버가 되겠습니다.)
• 인증 및 토큰
  • Authentication: 인증, 접근 자격이 있는지 검증하는 단계를 말합니다.
  • Authorization: 인가, 자원에 접근할 권한을 부여하는 것입니다. 인가가 완료되면 Access Token이 클라이언트에게 부여됩니다.
  • Access Token: 만료 기간이 있는 인증 토큰입니다.
  • Refresh Token: Access Token 만료시 이를 갱신하기 위한 용도로 사용하는 Token입니다.

여기까지만 봐도 OAuth2.0에서 꽤나 달라진점을 찾을 수 있으실겁니다.

 

그럼 이제 OAuth2.0이 제공한다는 다양한 인증방식에 대해 살펴볼까요??

---

OAuth 2.0의 인증종류

 

Authorization Code Grant (권한 부여 승인코드 방식)

 

Authorization Code Grant 방식

가장 많이쓰이고 기본이 되는 방식입니다. 순서는 아래와 같습니다

1. Resource Owner가 Client에 Resource Server사용요청을 합니다
2. Client는 해당 Resource Owner가 권한이 있는지 알기위해 Authorization Server에 Client에서 자체 생성한 Authorization Code(랜덤 코드)를 전달합니다
3. Resource Server에서 로그인 팝업이 뜨고 Resource Owner가 로그인합니다.
4. 로그인이 성공하면 Authorization Server는 Authorization Code 요청시 전달받은 redirect_url(Client)로 Authorization Code를 전달합니다
5. Client는 이 Authorization Code와 ClientId, ClientSecret (쉽게말해서 Client의 아이디 비밀번호)를 이용해서 Authorization Server에 AccessToken을 요청해서 받습니다.
6. 1번에서 Resource Owner의 요청을 수행하기 위해 AccessToken으로 Resource Server에 접근합니다.

 

Implicit Grant (암묵적 승인 방식)

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식입니다.

1. Resource Owner가 Client에 Resource Server사용요청을 합니다
2. Client는 해당 Resource Owner가 권한이 있는지 알기위해 Authorization Server에 ClientId를 전달합니다.
3. Resource Server에서 로그인 팝업이 뜨고 Resource Owner가 로그인합니다.
4. 로그인이 완료되면 바로 Client는 바로  AccessToken을 받습니다.
5. 1번에서의 Resource Owner의 요청을 수행하기 위해 AccessToken으로 Resource Server에 접근합니다.

Resource Owner Password Credentials Grant (Resource Owner 자격증명 승인 방식)

ClientId 와 ClientSecret 즉 Client의 아이디 비밀번호 만으로 Access Token을 받는 방식입니다. 이 경우는 보안상 Client가 타사의 서비스일경우 적용하면 안됩니다. 자신의 서비스에서 제공하는 애플리케이션에서만 사용되는 인증방식입니다.

1. Resource Owner가 Client에 Resource Server사용요청을 합니다
2. Client는 자신의 ClientId, ClientSecret을 이용해서 Authorization Server에 인증을 요청하고 Access Token을 받습니다.
3. 1번에서의 Resource Owner의 요청을 수행하기 위해 AccessToken으로 Resource Server에 접근합니다.

Client Credentials Grant (클라이언트 자격증명 승인 방식)

Client의 자격증명만으로 AccessToken을 획득하는 방식입니다. OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용됩니다.

1. Resource Owner가 Client에 Resource Server사용요청을 합니다.
2. Client가 Authorization Server에 Access Token을 요청하고 받습니다 (요청시 특별한 인증코드없음)
3. 1번에서의 Resource Owner의 요청을 수행하기 위해 AccessToken으로 Resource Server에 접근합니다.

---

오늘은 이렇게 OAuth에 대해서 알아보았습니다. 정보보안이 훨씬더 중요해진 요즘 꼭 필요한 프로토콜인것 같습니다! :))

 

 

출처:
- OAuth와 춤을
- OAuth와 춤을
- OAuth 란 무엇일까
- [oauth] OAuth 2는 OAuth 1과 어떻게 다릅니까?)
- OAuth 2.0 동작 방식의 이해