OAuth란?
OAuth
OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고, 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 어플리케이션의 접근권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다!
라고 했지만 잘 이해가 가지 않으니, 더 친절히 설명된 글을 읽어보자
Facebook과 Tweeter를 생각해보자! 각 프로그램은 외부 서비스에서 Facebook이나 Tweeter의 일부 기능을 사용할 수 있게 한 것이다. 이때 외부 서비스와 연동되는 Facebook이나 Tweeter에 직접 로그인해야 하는 것이 아니라, 별도의 인증 절차를 거치면 다른 서비스에서 Facebookrhk Tweeter의 기능을 이용할 수 있게 된다. 이러한 방식에서 사용되는 인증 절차가 OAuth이다!
“웹, 앱 서비스에서 제한적으로 권한을 요청해 사용할 수 있는 키를 발급해주는것”
그래도 이해가 되지 않는다면, 이 예시를 보자!
어떤 사원이 자신의 사원증을 이용하여 회사에 출입 및 활동을 하는 것은 “로그인” 이고, 어떤 이가 안내데스크에서 방문증을 수령하여 출입하는 것은 “OAuth” 라고 할 수 있다. 방문증은 사전에 정해진 곳만 다닐 수 있는 것이기 때문에, 방문증을 가진 사람의 권한과 사원증을 가진 사람의 권한은 다르다. 즉, 직접 서비스에 로그인한 사용자와 OAuth를 이용해 권한을 인증받은 사용자가 할 수 있는 일은 다르다.
OAuth는 인증을 위한 오픈 스탠더드 프로토콜로, 사용자가 Facebook이나 트위터 같은 인터넷 서비스의 기능을 다른 어플리케이션(데스크톱, 웹, 모바일 등)에서도 사용할 수 있게 한 것이다.
OAuth 1.0 : 비공식 논의체에 의해 최초로 만들어진 것
OAuth 2.0 : 드래프트 단계에 있는 것으로, IEFT OAuth 워킹 그룹이 주축이 되어 만든 것이다. OAuth 2.0은 1.0과 호환되지 않지만, 인증 절차가 간략하다는 장점이 있다. 아직 최종안이 나오진 않았지만, 여러 인터넷 서비스에서 OAuth2.0을 사용하고 있다.
OAuth 1.0의 동작 방식
User, Consumer, Service Provider로 구성된다. 3-legged OAuth라고도 한다.
위 그림과 같은 순서로 진행된다.
User가 Consumer(서비스)로 로그인을 요청하면, Consumer는 해당 로그인 페이지(Service Provider)를 띄위준다.
User는 로그인을 수행하고, Service Provider는 인증 토큰을 Consumer(서비스)에게 전달한다.
👉 사용자의 아이디/패스워드를 몰라도 토큰을 이용해 허가받은 API에 접근이 가능하다.
👉 필요한 API에만 제한적으로 접근할 수 있어 권한제어가 가능하다.
👉 저장되어 있는 인증토큰이 유출되더라도, Service관리자가 인증토큰의 권한만 취소하면 된다.
👉 사용자가 Service Provider의 패스워드를 변경하더라도, 인증토큰은 유효하다.
OAuth 2.0에서의 개선사항
OAuth 2.0은 1.0과 호환되지 않고, 용어부터 다르다.
- Resource Owner(서비스)
- Authorization Server(인증 서버)
- Resource Server(REST API)
- Client(사용자) 클라이언트와 리소스 오너가 중요한데, 인증서버와 리소스 서버는 보안과 사요으이 제한을 걸어주는 OAuth를 위한 요소일 뿐이다.
OAuth 1.0에서는 HTTPS가 필수로 필요하다. URL 인코딩이 필요없다. 더 다양한 웹/모바일 등 다양한 시나리오에 대응이 가능하다.
암호화가 필요없으며, HTTPS를 사용한다.
Access Token의 Life-time을 지정하여 만료일을 설정 가능하다!
커다란 서비스의 경우, 인증 서버를 분리하거나 다중화할 수 있어야 하는데, 2.0에서는 Authorization Server의 기능을 명확히 하여 이를 고려하였다.
EX)
- Client가 어떤 사이트를 이용해보려고 하는데, Facebook을 통해서 가입할 수 있다는 버튼을 발견한다. 버튼을 누르면, Facebook 로그인 창이 나와서 로그인을 진행한다. Client와 Resource Owner간의 통신
- 로그인을 하게되면, 서버에서 승인을 받았다는 것이다. 로그인 후에 해당사이트의 접근을 허용할 것인가? 확인창이 뜨고, 허용을 하게 되면 Access Token을 받게된다 Client와 Authorization Server와의 통신
- 이 Token을 이용하여 해당 서비스를 이용할 수 있다. Access Token의 id를 이용하여, 서버의 제한된 resource를 사용할 수 있다.
👉 정식 명칭으로 다시 설명을 써보자면!
- 먼저 클라이언트 가 Redirect URL을 포함하여 Resource Owner 로 권한 요청을 한다.
- Resource Owner 는 권한 증서를 제공한다.
- 클라이언트 는 권한증서를 인증 서버 로 보내어, Access Token을 요청한다.
- 인증 서버 는 클라이언트 에게 Access Token(with 유효기간)을 발급한다.
- 클라이언트 는 Access Token을 이용하여 REST API 에 자원을 접근할 수 있게 된다.
- Access Token이 만료되면, Refresh Token을 이용하여 재발급받을 수 있다.