OAuth 프로토콜의 이해와 활용 1 - 필요성과 역사

 

 

WWW(World Wide Web)가 세상에 나온 지도 거의 30년이 되었고, 그동안 세상은 눈부시게 발전했습니다.

 

전화선을 꽂아 쓰던 PC통신의 시대를 넘어 초고속 인터넷이 보급되며 사람들은 누구나 쉽고 빠르게 정보를 공유할 수 있게 되었고,

그와 더불어 IT산업은 폭발적으로 성장하기 시작하였습니다.

 

2000년대 들어, 소셜 네트워크 서비스들이 등장하면서 인터넷은 정보를 얻는 공간에서 지인들과 나의 일상을 공유하는 일상적인 공간으로 변하였습니다.

 

사람들은 전화 대신 페이스북으로 안부를 물었고, 쉽게 다른 사람의 소식을 전해 들을 수 있게 되었습니다.

 

점점 더 많은 사람들이 웹을 통해 인터넷에 접속하기 시작했고, 

 

2010년대 들어 스마트폰을 중심으로 한 모바일 플랫폼이 빠르게 확산되면서 이제 세상은 웹을 중심으로 돌아간다고 해도 과언이 아니게 되었습니다.

 

웹을 사용하는 사람들이 급격하게 늘어나면서, 다양한 필요와 욕구가 생겨났고 이에 맞춰 기업들은 서비스를 내놓았습니다. 

 

이제 한 사람이 여러 개의 온라인 서비스를 사용하는 것은 이상한것이 아닙니다.

 

그러다 보니, 한 서비스를 사용하면서 내가 사용하는 다른 서비스의 정보에 쉽게 접근하기 바라는 사람들이 많이 늘어났습니다.

 

사용자들은 트위터에 있는 웃긴 글을 페이스북에 공유하기를 원했고, 에버노트에 구글 캘린더를 붙여넣고 싶어 했습니다.

 

이에 따라, 온라인 서비스들은 안전하고 쉽게 다른 서비스에 있는 사용자의 정보에 접근할 방법이 필요하게 되었습니다.

 

그러나 OAuth의 등장전까지 다른 서비스에 대해 접근하기 위한 인증 및 인가 표준이 없어서,

 

사용자들의 계정, 즉 아이디와 비밀번호를 가지고 직접 인증 절차를 통과하였습니다.

 

이는 보안상 아주 취약한 방법인데, 이유를 아래 슬라이드를 보면서 함께 알아보겠습니다.

 

 

 

만약 한 온라인 서비스 A에서 Google에 있는 주소록 정보에 접근하여야 한다고 생각해 봅시다.

 

OAuth가 존재하기 전이기 때문에, A 서비스에서는 사용자의 구글 아이디와 패스워드를 받아 직접 API를 호출합니다.

 

 

 

그렇게 사용하던 도중에 악의적인 목적을 가진 해커가 중간에서 유저의 계정을 탈취합니다.

해커는 이렇게 탈취한 계정으로 사용자의 구글 드라이브에 접근하여 사용자의 비밀스러운 정보들을 가져갑니다.

 

A 서비스에서는 주소록 정보만 필요했다는 것을 생각하세요.

 

구글은 하나의 계정으로 모든 서비스에 접근할 수 있기 때문에, 계정이 한 번 탈취되면 사실상 모든 서비스에 대한 접근 권한을 얻는 것이나 마찬가집니다.

 

더 중요한 건 사용자가 A 서비스만 사용한다는 보장이 없다는 겁니다.

이런 방식으로 인증을 진행하는 서비스가 많으면 많을수록 사용자의 계정이 탈취될 가능성은 더욱 높아집니다.

 

또한, 사용자가 계정을 몇 개의 서비스에 돌려쓰고 있는 경우 하나가 뚫리면 여러 개의 서비스가 동시에 뚫리게 됩니다.

 

이런 위험성 때문에 몇몇 서비스 회사들은 각자 인증체계를 구축해서 운용하였는데, 대표적으로 구글의 AuthSub나 야후의 BBAuth등이 있습니다.

 

Yahoo!의 BBAuth의 흐름도. 현재 OAuth의 인증 과정과 유사하다. 원문 보기

 

이건 다른 서비스에 있는 정보를 사용하려는 주체에게 큰 장벽이었는데, 각 서비스가 제공하는 방식의 인증 체계에 모두 대응해야 했기 때문입니다. 

 

생각해보세요. 구글과 BBAuth, 아마존 등의 많은 서비스를 한 번에 연동해야 하는데 모두 다른 인증 체계에 각각 맞추어야 하면, 개발뿐만 아니라 유지보수도 큰 부담입니다.

 

개발자는 각각 다른 인증 체계가 설명된 문서를 모두 확인해야 하고, 만약 한 서비스의 인증 체계가 수정된다면 같이 수정해 주어야 하니까요.

 

게다가, 모든 서비스의 인증 체계가 모두 좋은 건 아니라서 걔 중에 보안 수준이 낮은 인증 체계가 있다면 문제가 생길 여지가 큽니다.

 

이런 이유 때문에 다른 서비스에 있는 사용자의 정보에 안전하고 쉽게 접근하는 건 정말 힘든 일이었습니다.

 

그렇게 시간이 흘러 2006년, 트위터에서 일하던 블레인 쿡(Blaine Cook)은 Open ID를 트위터에 탑재하고 있는 일을 하고 있었고 소셜 북마크 사이트인 Ma.gnolia에서도 회원이 대시보드에서 OpenID를 통해 서비스에 접근하는 방법을 생각하고 있었습니다.

 

이에 쿡, 크리스 메시나(Chris Messina), Larry Halff (Magnolia 개발자)는 데이비드 리코던(David Recordon)을 만나서, Open ID를 사용해 트위터와 매그놀리아의 인증을 위임하기 위한 API를 논의하였습니다.

 

만나서 얘기를 하다 보니까, 지금까지 API 접근을 맡기는 표준적인 방법은 없다는걸 깨닫게 됩니다.

 

이 순간이 바로 구글부터 새로 시작하는 스타트업까지 모두 사용하는 OAuth가 탄생하는 순간입니다.

 

이후 2007년 4월 OAuth의 초안이 작성되었고 7월에 사양 초안, 10월에 OAuth Core 1.0의 초안이 작성되게 됩니다.

 

2008년 11월에는 제73회 IETF(국제 인터넷 표준화 기구, Internet Engineering Task Force)에서 OAuth를 표준화하자는 비공식 회담이 열리고 긍정적인 반응을 얻었고

 

2010년에는 RFC 5849로 등록된 OAuth 1.0 버전이 나오게 됩니다. 그 해 10월 31일, 트위터의 모든 3rd Party 서비스들은 필수적으로 OAuth를 사용하게 됩니다.

 

이보다 개량된 OAuth2.0은 2012년 나왔고, RFC 6749와 RFC 6750으로 등록되어 있습니다.

 

2020년 현재 API를 제공하는 대다수의 국내외 서비스들은 OAuth를 사용하여 인증 및 권한 부여 체계를 갖추고 있습니다.

 

OAuth를 사용하면 비밀번호 탈취 위험으로 인한 골치아픈 인증 문제와 모든 서비스에 접근 가능한 권한 문제를 해결할 수 있습니다.

 

다음 시간에는 OAuth가 무엇인지, 또 어떤 흐름으로 이런 문제들을 해결하는지 알아보겠습니다.

 

 

참고자료 : 

 

https://en.wikipedia.org/wiki/OAuth

OAuth - Wikipedia