Oauth에 대해서

Oauth는 요즘 자주 보이는 인증 방식이다. 네이버, 페이스북 등의 계정 정보를 활용한 인증 서비스를 제공하는 곳을 많이 보았을 것이다. 그렇다면 이런 인증 방식은 어떻게, 왜 사용하게 된 것일까?

어떤 시스템에서 외부 시스템에 접근하기 위하여 사용자의 계정 정보(아이디, 비밀번호 등)을 사용하는 것은 보안상 좋지 않다. 따라서 사용자의 인증을 받아 토큰을 발급 받으면 그 토큰 만을 사용함으로써 사용자의 계정 정보는 불필요하게 되어 보안을 유지할 수 있는 것이다. 추가적으로 사용자의 권한까지 조절할 수 있도록하면 서비스적으로 더 좋을 것이다. 이것이 Oauth의 기본 개념이다.

Oauth 1.0a

Outh는 현재 2.0 버전을 달리고 있는데, 먼저 등장한 1.0a 버전에 대하여 알아보자.(1.0a 버전도 현재까지 사용되고 있다.) Oauth 1.0a는 사용자(user), 컨슈머(consumer), 서비스 프로바이더(service provider)의 3가지 요소로 이루어져있어 3-legged auth라고도 불린다. 여기서 컨슈머는 사용자가 이용하고자 하는 서비스고 서비스 프로바이더는 인증 api 서비스라고 보면 된다.

Oauth를 적극적으로 도입한 대표적인 예로 트위터가 있다. 잘 요약된 도식이 있으니 참고해보자.

사용자가 컨슈머에게 트위터 API 서비스를 요청하면 컨슈머는 트위터 로그인 화면으로 사용자를 리다이렉트 시켜주고, 로그인을 한 후에 권한 설정까지 마치면 트위터 API는 컨슈머에게 인증 토큰을 전달하게 된다. 이후로는 사용자가 컨슈머에 접근할 때 인증 토큰만을 사용하게 되는 것이다. 만약 컨슈머가 이 인증토큰을 유출시키더라도 사용자는 트위터 API 서비스에서 인증 토큰에 대한 권한을 취소하면 된다.

Oauth 2.0

2.0에선 무엇이 달라졌을까. 그야말로 모든 것이 달라졌다고 해도 무방하다. Oauth 2.0은 Oauth 1.0a와 호환이 되지 않고 그 규모가 커졌다. 이름도 1.0a는 프로토콜(protocol)인 반면에 2.0은 프레임워크(framework)라는 용어를 사용한다. 2.0에서는 좀 더 간편한 인증과 다양한 인증 방식, 더 높은 확장성을 지원한다. 그리고 1.0a 때와 사용하는 용어도 달라졌는데, 사용자(Resource Owner), API 서버(Resource Server), 인증 서버(Authorization Server), 써드파티 어플리케이션(Client)으로 바뀌었다. 인증 서버를 따로 두었다는 점이 특징이다.

Oauth 2.0의 작동 방식을 요약한 이미지가 있어서 가져왔다.

사용자가 인증을 요청하면 써드파티에서 인증 서버에서 토큰을 받아 API 서버에 인증을 함으로써 보호된 자원을 받아 사용할 수 있는 것이다.

Oauth는 API를 붙이는 간단한 작업만으로도 사용할 수 있다고 하니 개인 프로젝트에 적용해보면 회원가입 기능을 개발하는 비용이 줄어서 좋을 것 같다.

참고 출처 : http://earlybird.kr/1584

                 http://bcho.tistory.com/942