OAuth
이번 주 CS스터디의 주제는
OAuth였습니다.
다른 스터디 분들이OAuth2.0에 대해서 자세히 준비해주실 것 같아 탄생 배경을 위주로 준비해봤습니다.
목표
OAuth의 개념이나 활용은 많이 알고 계시지만 왜 탄생하게 되었는 지 아시는 분은 적은 것 같습니다.
OAuth가 왜 생기게 되었는지 알아봅시다!
탄생 배경
OAuth는 트위터의 개발자와 Ma.gnolia 개발자의 협업 과정에서 탄생했습니다.
Ma.gnolia는 웹페이지 북마킹을 공유할 수 있는 소셜 북마크 서비스입니다.
Ma.gnolia와 트위터는 사용자가 OpenID를 통해 인증하고, 이를 바탕으로 타 서비스의 사용자 데이터에 접근하고자 하였습니다.
하지만 보안의 문제로 비밀번호를 공유하지 않고도 타 서비스의 권한을 부여받을 수 있는 프로토콜의 필요성을 느꼈습니다.
OAuth 이전
OAuth 탄생 이전에는 각 회사 별로 독자적인 인가 방식을 사용했습니다. 구글의 AuthSub, 야후의 BBAuth 방식 등이 있는데 이러한 인가 방식을 표준화한 것입니다.
사용자가 Ma.gnolia에 직접 패스워드를 입력하고 이를 활용하여 트위터에 인증하는 방식은 보안적으로 굉장히 위험합니다. 트위터가 아무리 보안 조치를 잘해도 Ma.gnolia가 뚫리면 무용지물이 되겠죠..!
OAuth 1.0
따라서 사용자의 비밀번호를 Ma.gnolia에 공유하지 않고, Ma.gnolia에 트위터에 대한 접근 권한을 인가할 수 있는 방법이 OAuth입니다.
OAuth와 같은 인가 방식을 사용하지 않고 사용자가 Twitter에 직접 패스워드를 입력하여 인증을 하고, 트위터는 Ma.gnolia에게 접근 권한을 부여합니다. Ma.gnolia는 부여받은 권한을 통해 Twitter에 접근할 수 있고 이를 활용하여 사용자에게 서비스를 제공할 수 있습니다. (실제 동작에서는 다른 과정이 더 있습니다)
OAuth 1.0의 문제점(1)
하지만 초기 OAuth에는 여러 문제점이 있었습니다.
scope가 표준화되지 않아 모든 접근 토큰이 동일한 수준의 권한을 가지게 되는 경향이 생겼습니다.
또한 Client측에서 OAuth 구현이 복잡했습니다. 모든 요청에 대해 복잡한 서명 과정이 존재했고 OAuth의 매개 변수 또한 정규화해야 하고 파라미터의 순서, 인코딩 방식의 차이로도 서명이 무효화 될 가능성이 존재했습니다.
OAuth 1.0 서명 원문 예시
서명 원문 예시가 궁금하면 확인해보세요!
OAuth 1.0a버전에서는 매개 변수를 알파벳 순서로 정렬해야 했다고 합니다.
OAuth 1.0의 문제점(2)
또한 토큰 유효 기간을 정의하지 않아 서비스 제공자가 알아서 만료 정책을 정해야 했습니다. 이에 장기간 토큰을 보유하게 될 경우 보안의 위험성이 증가합니다.
2007년에 OAuth가 탄생했고, 2008년에 아이폰에 3G가 도입되었습니다.
이에 점차 모바일 환경에서 OAuth의 수요가 증가하게 되면서 웹 브라우저에서만 사용 가능한 OAuth 1.0의 개선이 필요해집니다.
마치며
OAuth 1.0의 여러 문제점들은OAuth 2.0에서 개선됩니다. 이 글을 읽으신 분들은 OAuth 1.0의 문제점이 어떻게 개선되었을까 기대하며 OAuth 2.0을 공부해보시는 것을 추천드립니다! 또한 아래 영상이 많은 도움이 되어서 꼭 봐보셨으면 좋겠습니다.
