대부분 사람은 일상 속에서 아이디, 비밀번호를 입력합니다. 그 행동이 로그인입니다.
모두에게 공개되어도, 문제되지 않는 콘텐츠라면 로그인은 실효성이 없습니다. 네이버에서 로그인하고 나서 볼 수 있는 콘텐츠를 보십시요.
이메일, 캘린더, 메모, 주소록 등 공개되는 경우, 정상적으로 생활 할 수 없을 것입니다. 보호를 받아야하는 콘텐츠는 소유자인 것을 증명하는 수단이 필요합니다. 그 개념이 바로 Authentication(인증)이고, 로그인을 통해서 행해집니다. 전통적으로 사용하는 방법입니다.
소유자만 콘텐츠를 이용할 때에는 사용에 불편함이 없었습니다. 세월이 흘러 페이스북, 트위터, 인스타그램과 같은 SNS가 활성화되고 스마트폰도 활성화되면서 애플리케이션이 많이 생겨났습니다. 그로 인해 콘텐츠 사용도 필요하게 되었고 기존 방법을 사용하려면 콘텐츠 소유자가 아이디, 비밀번호를 매번 알려줘야 합니다. 신뢰할 수 없는 애플리케이션의 경우 어떻게 해야 할지, 망설여지게 됩니다.
결국 소유자는 허용하고 싶은 콘텐츠만 전달하고 싶은 상황에 직면하게됩니다. OAuth 2.0은 그 역할을 대신 해주는 권한 부여 프레임워크 입니다.
소유자를 증명하는 Authentication(인증)과, Authorization(권한 부여)가 함께 구성되어야만 정상적으로 사용할 수 있습니다. 실제 사례를 한가지 들어보겠습니다.
게임 커뮤니티 사이트인 루리웹의 로그인 화면입니다. 그림 하단에 네이버, 다음 로그인 버튼이 보입니다.
소유자의 정보를 제공받는 조건으로 루리웹 로그인을 대체하는 기능입니다. 네이버 아이디로 로그인 버튼을 클릭하면 아래와 같이 로그인 화면으로 이동합니다.
소유자를 증명하기 위해 Authentication(인증)을 해야 합니다. 아이디, 비밀번호를 입력하여 로그인합니다.
Authentication(인증)이 성공하면 소유자에게 동의를 구합니다. 동의하게 되면 Authorization(권한 부여)가 되고 네이버에 있는 프로필 정보를 루리웹에게 제공합니다.
위 과정이 모두 끝나면 네이버 프로필 정보로 루리웹을 사용할 수 있게 됩니다. 소유자는 아이디, 비밀번호를 알려주지 않고, 루리웹에게 프로필 정보를 전달하였습니다.
OAuth 2.0은 Authorization(권한 부여) 기능을 담당하며, 사용하려면 반드시 소유자를 증명할 수 있는 Authentication(인증)이 함께 구성되어야 합니다.
RFC 6749는 위에서 설명한 OAuth 2.0의 규칙이 정의된 문서입니다. 각 역할을 아래와 같이 설명하고 있습니다.
Resource Owner(리소스 소유자)
보호된 콘텐츠(예: 이메일, 캘린더, 메모, 주소록)에 접근할 수 있는 권한을 부여하는 소유자를 의미합니다.
Resource Server(리소스 서버)
보호된 콘텐츠를 관리하는 서버이며, 리소스 소유자가 권한을 부여했다는 것을 증명하는 Access Token을 이용하여 보호된 콘텐츠를 받을 수 있습니다.
Client(클라이언트)
리소스 소유자를 대신하여 리소스 서버에 보호된 콘텐츠를 요청하는 애플리케이션입니다.
Authorization Server(권한 부여 서버)
리소스 소유자의 권한 부여를 위임받아서 진행하고, 성공적으로 인증된 클라이언트에게 그 결과로 Access Token을 발급합니다.