oAuth 2.0
oAuth는 인증 및 권한부여를 관리하는 범용 프레임워크로 사용자가 Facebook이나 트위터 같은 외부 서비스의 일정 기능을 사용할 수 있게 한다.
1. oAuth 역사
oAuth의 시작은 2006년 트위터 개발자와 소셜북마크 서비스 Gnolia 개발자가 인증 방식을 논의하면서 시작되었다. 개발자들은 그때까지 API 접근 위임에 대한 표준이 없다는것을 알고 oAuth 제안서를 만든다. 이후 이 활동은 지지를 받았고 2007년 oAuth 1.0 초안이 발표된다.
이후 oAuth 1.0은 보안문제 일부를 수정하여 2009년 oAuth 1.0 Revision A(oAuth 1.0a) 으로 업그레이드 된다.
2008년에는 oAuth 표준화를 위해 IETF 회합에서 논의가 진행되었고 이는 큰 지지를 받아 2010년 oAuth 1.0 프로토콜 표준안이 RFC5849로 발표되었다. (base가 되는 버전은 oAuth 1.0a 이다.)
oAuth 1.0은 웹이 아닌 앱에서 사용하기 힘들다는 단점이 있다. 또한 절차가 복잡하여 구현 라이브러리를 만들기 어렵다.
현재 최신버전인 oAuth 2.0은 이런 단점을 개선한 것이다.
참고로 oAuth 2.0은 이전버전과 호환이 되지 않는다.
1.0은 만들어지고 어느정도 시간이지난 후 IETF 표준이 된 반면 oAuth 2.0은 초기부터 IETF 표준 프로세스 안에서 만들어졌다.
2. 인증과 권한부여
oAuth는 Open Authorization의 약자로 “공개 권한 부여”의 의미이다.
oAuth 자체는 인증과 권한부여라는 두가지 기능을 다 하는데 주 목적은 데이터에 접근할 수 있는 권한을 부여하는 것이다.
예를 들어 내 앱에서 사용자의 페이스북 게시물을 읽어서 보여주고 싶다.
- 우선 내 앱은 페이스북 개발자센터에 내 앱을 등록하여 게시물을 읽을 수 있는 기능을 사용할 것이라고 명시할 것이다.
- 사용자는 내 앱을 사용할때 페이스북 로그인을 할 것이다.
- 로그인을 하면 내 앱에서는 페이스북에 게시물을 읽을 수 있도록 허락해달라고 요청할 것이다.
- 이 요청에 따라 페이스북 페이지가 뜨면서 이 앱이 게시물을 읽도록 허용할 것이냐고 사용자에게 묻는다.
- 확인을 누르면 내 앱에서 사용자의 게시물이 보인다.
여기서 권한부여란 3,4번 과정이다.
즉, 내 앱이 페이스북 게시물을 읽을 수 있도록 권한을 요청하고 이를 페이스북에서 허락하는 과정이다.
3. protocol flow와 용어
oAuth 2.0의 권한 허가 절차는 아래와 같다.
3.1. 용어
3.1.1. Client
사용자를 말하는게 아니라 권한을 사용할 서비스를 의미한다.
예를 들어 페이스북 게시물을 읽어서 보여줄 앱을 말한다.
3.1.2. Resource Owner
리소스를 소유한 사람. 실제 사용자를 의미한다.(또는 이를 위임받은 서버)
예를 들어 어떤 앱이 페이스북 게시물을 보여줄때 실제 게시물의 소유자는 앱을 사용하는 사용자이다.
3.1.3. Authorization Server
인증 서버로 일반적인 로그인 서버와 다르다.(같을 수도 있고 다를수도 있음)
flow 상에서 인증서버가 하는 역할은 “사용자에게는 허가를 받았는데 이 허가를 기반으로 이 서비스에서 특정 기능을 사용할 수 있도록 권한을 달라”고 하는 것이다.
인증이 되면 Access Token 을 부여받는다.
3.1.4. Resource Server
데이터가 존재하는 서버이다.
인증 이후 인증서버로 부터 받은 Access Token을 통해 데이터에 접근할 수 있다.
3.2. Flow
- Client가 Resoure Owner 에게 권한을 요청한다. 이 때 권한 요청은 소유자에게 직접 할 수도 있고, 권한서버를 통해 간접적으로 할 수도 있다.
- Resource Owner가 권한을 허가하면 Client는 권한 증서(Authorization Grant)를 받는다.
- 증서를 받은 Client는 Authorization Server에 이를 보낸다.
- Authorization Server는 전달받은 증서의 유효성을 검증하고 유효하다면 Access Token을 발급한다.
- Access Token을 발급받은 Client는 실제 데이터를 불러올 수 있는데 Resource Server에 데이터를 요청할때 Access Token을 함께 전달한다.
- Resource Server는 Token의 유효성을 검사하고 유효하다면 요청을 처리해준다.
4. Access Token과 Refresh Token
Access Token은 정상적으로 인증이 됬을때 Client에게 발급된다.
이 Token은 보호된 자원에 접근할때 권한 확인용으로 사용되는데 기존 아이디나 비밀번호등 인증에 필요한 형태가 토큰 하나로 표현됨으로써 리소스 서버입장에서 간편하다.
Access Token은 발급됬을때 유효기간이 정해진다. 만약 유효기간이 지나면 새로운 Access Token을 발급받아야 하는데 이 때 Refresh Token이 활용된다.
권한서버는 Access Token을 발급할때 Refresh Token도 함께 발급한다.
Access Token의 기한이 지나면 Refresh Token을 통해 권한 서버에 다시 요청을 하게 되고, 권한 서버는 이를 통해 Access Token을 갱신해준다.
Refresh token을 따로 두는것은 Token 기반 인증의 안정성 때문이다.
일단 Access Token이 탈취되면 유효기간동안 제제없이 인증이 허가된다. 이 때문에 Access Token의 유효기간은 짧게 두고, 유효기간이 지난 후 다시 Token을 갱신할 수 있는 Refresh Token을 따로 두는 것이다.
5. Authorization Grant의 4가지 형태
이 Client(앱)가 다른 서비스의 일정 기능을 사용할 것이라고 Resource Owner(서비스의 실제 사용자)에게 허가를 받는데 이 허가를 받는 방식이 크게 4가지가 있다.
참고로 oAuth 2.0은 아래 4가지 외에 추가적인 인증방식을 적용할 수 있다고 열어두었다.
5.1. Authorization Code
Client가 Resource Owner에게 직접 권한을 요청하는게 아니라 Resource Owner가 Authorization Server에게 인증을 받음으로써 권한을 요청하고 허가하는 형태이다.
이 때 Authorization Server가 하는 역할은 로그인 인증서버의 역할을 하게 된다.
일반적으로 구글, 페이스북들 모두 이런 방식을 사용한다. 이 때문에 구글, 페이스북 로그인을 하라고 요청 받는 것이다.
이 방식을 사용하면 로그인 후 Authorization Code를 발급받고 이 코드를 다시 Authorization Server에게 전달하게 된다.
Authorization Server는 2가지 역할을 하게 되는데, 서버 구현에 따라 이 둘을 분리할 수도 있을 것이다.
5.2. Implicit
Implicit는 Authorization Code와 비슷한데 중간 한단계를 축소한 것이다.
위에서 Authorization Server는 처음에는 로그인을 했고 두번째는 권한 허가 역할을 했다. 이런 과정을 하나로 합쳐 로그인 후 Authorization Code를 리턴하는게 아니라 바로 Access Token을 리턴해 주는 것이다.
과정이 줄어들어 편해지는 대신 보안성이 낮아진다.
어떤 보안이 낮아지는지는 모르겠음…
5.3. Resource Owner Password Credentials
Access Token을 발급받기 위한 권한증서 자체가 ID/PW 이다.
이 때의 문제는 ID/PW를 Client(앱)에 직접 입력해야 한다는 점이다.
Client를 신뢰할 수 있다면 괜찮으나 신뢰할 수 없다면 이런 ID/PW 정보를 직접 입력받는다는게 보안에 문제가 된다.
5.4. Client Credentials
Client 인증 방식으로 위 3가지 형태와 다른 형태이다.
이는 Resource Owner가 사용자가 아니라 Client 자체인 경우이다.
예를 들어 구글 지도 서비스를 사용하고 싶다고 할때 사용자 인증을 받는게 아니라 앱 자체만 등록하여 사용하는것과 같다.
6. oAuth를 이용해 내 서버에서 인증 사용하는 방법
- 페이스북 로그인 (oAuth)
- 결과로 Access Token 받음
- 내 서버에 Access Token 전달
- 내 서버에서 페이스북 서버를 통해 Access Token이 유효한지 확인하고 회원 기본정보를 조회.
- 이 기본정보로 내 서버에 회원 가입 시킴.
- 내 서버에서 사용하기 위한 Token 발급하여 Client에 응답.
- Client에서 서버 사용할때는 내 서버가 발급한 Token 사용.
[참고 문서]
댓글남기기