Google Authentication 분석 part 1 : web-based application

revise 1; 2006/7/9, sso 부분 수정

간단히 읽어보고 문제점 위주로 정리하였습니다. 그렇다고 좋은 점이 하나도 없는 건 아니구요. 비판적인 관점에서 Google Authentication 기술을 살펴보겠습니다.

전체적으로 가장 큰 문제점은 다음과 같습니다.
1. 인증 request 메시지를 제외한 다른 메시지들은 사용자가 제어할 수 없다.
2. 세션 token(무제한으로 사용할 수 있는 토큰)과 single-use token(한번만 사용할 수 있는 토큰)이 있는데, 유효 시간이 (현재는) 없다.

기술을 살펴보면 4가지 operation이 있습니다.
1. AuthSubRequest - token을 발급하는 작업. 사용자가 인증 절차를 수행해야 합니다. 세션 token 또는 Single-use token을 선택할 수 있고, secure 모드도 선택적입니다.
2. AuthSubSessionToken - 만일 single-use 토큰을 발급했는데, 한 번 이상 사용해야 할 경우 세션 token으로 교환할 수 있습니다.
3. AuthSubRevokeToken - token을 쓸모없게 만들어 버립니다.
4. AuthSubTokenInfo - token이 유효한지를 체크합니다. single-use 토큰이라면 유효 결과를 전달하고, 해당 토큰은 쓸모없게 됩니다.

각각의 operation에 대해서 자세히 살펴보겠습니다. 설명은 http://code.google.com/apis/accounts/AuthForWebApps.html에 있으니 넘어가고, 문제가 될 부분을 집중적으로 보겠습니다.

0. 등록
- 특정 site가 구글에 가입하면, 사용자는 구글을 신뢰하는 것만큼 site를 신뢰할 수 있습니다.
- 그러나 구글에 굳이 가입하지 않아도 기본적인 동작은 가능합니다. 경고 메시지가 뜨고, 특정 구글 서비스는 secure 모드에서만 동작하기 때문에 전체 서비스를 사용하기에는 제약이 있을 듯 보입니다. 이 부분은 실제 테스트가 필요합니다.
- self signed 인증서를 만들어서 등록하면 된다고 하니, 이것도 조만간 테스트를 해봐야 겠습니다.^^
- 등록할 때 xml 파일을 만들어야 하는데, 이 때 명시된 TargetURLpath와 AuthSubRequest의 파라미터인 next가 다를 경우에는 어떻게 될까요? 이 문서에는 언급되어 있지 않습니다.

1. 토큰
- 세션 token을 사용하면 별도의 구글 로그인 절차 없이도, 사용자의 인증 정보를 이용하여 구글 서비스들을 제공할 수 있습니다. 또한 세션 token은 세션이 종료된다고 해서 사라지는 것이 아니라, AuthSubRevokeToken으로 삭제하지 않으면 계속 존재하는 것 같습니다. 편리성 측면에는 좋지만, 보안상으로는 문제가 있죠. 세션 token의 보관도 사용자나 site 측에서 안전하게 해야 한다며 책임을 넘기고 있습니다. 이 정보를 중간에서 가로채거나 변경할 경우에 문제가 발생할 것 같은데, 테스트를 해봐야 합니다.
- secure 모드를 선택하면 그나마 좀 더 안전하게 token과 관련된 작업을 수행할 수 있습니다. replay attack을 막기 위해 timestamp 필드도 추가했습니다.
- 문서를 읽어본 결과, token은 랜덤으로 만들어진 256byte 스트링입니다. 요청 메시지의 파라미터를 키로 하여 만들었다던지.. 그런 내용은 없고, Google 의 인증 서버가 token:요청 파라미터(return page, 사용하려는 구글 서비스 url, secure 모드 여부, token 종류) 를 매핑하고 있는 것 같습니다.
- 구글 Authentication은 많은 수의 token을 관리하지 못한다고 합니다. 실제로 한 서비스 당 한 사용자가 10개 이상의 token을 발급받지 못하도록 설정되어 있습니다. 이들 token의 보관, 삭제는 구글과 site간의 문제가 됩니다. 사용자는 관여할 수 없는 구조입니다. site가 악용하거나, 해커나 중간에서 token을 가로채어 쓴다면 어떻게 되나요? 이 문제는 세션 token에 유효 시간(expiration)을 반영해야 합니다. 또한 사용자는 자신이 발급해 준 token을 직접 관리할 수 있어야 할 것입니다. 구글 Authentication 서비스에 관련 기능이 추가되어야 한다고 봅니다.

2. AuthSubRequest
- secure 모드로 요청 메시지를 보낸 경우, 응답 메시지는 전혀 차이가 보이지 않습니다. 물론 사용자가 보는 화면에서 경고 메시지가 안뜨고, 신뢰하는 사이트라는 증거들은 보이겠죠. 하지만, 응답 메시지에 있는 토큰의 서명 또는 암호화 작업이 있으면 더 좋을 것 같습니다.

3. AuthSubSessionToken
- token을 세션 token으로 변경하는데 data 파라미터를 살펴보면 '접근하려는 url' 주소를 적게 되어 있습니다. AuthSubRequest의 scope에 해당하는 내용으로 보입니다. 만약 이 정보를 이전 token이 유지하고 있는 정보와 다르게 설정한다면 어떻게 될까요? 제 생각으로는 차단될 것 같지만, 굳이 똑같은 정보를 요구하는 저의가 의심가는 군요. 테스트가 필요합니다.
- sig 파라미터는 secure 토큰에 대한 서명 정보입니다. data 부분은 얼마든지 조작될 수 있다는 것이죠. 여전히 data 부분이 필요한 이유에 대해서 의문이 갑니다.
- 응답 메시지로 세션 token과 유효 시간(expiration)이 전송되지만, 현재는 유효 시간이 의미가 없다고 합니다. 왜 이 부분을 쓰지 않을까요? session의 유효 시간에 의존되는 것도 아니고, 사용자의 접속이 없어도 자유롭게 악용될 수 있는 이유가 됩니다.

5. AuthSubRevokeToken
- 세션 token은 삭제되지 않기 때문에, 반드시 강제로 종료시켜야 합니다. 이건 참 비효율적이라고 볼 수 있죠. 구글 인증 서버도 token 정보를 평생 유지해야 하며, 세션 token이 악용될 소지도 존재합니다.
- 삭제 요청이 성공할 경우는 HTTP 200 메시지를 전달한다고 하는데, 실패할 경우에 대해서는 언급되어 있지 않습니다.

6. AuthSubTokenInfo
- 응답 메시지에 Target이라는 새로운 파라미터가 등장합니다. 제 생각으로는 AuthSubRequest의 next 파라미터인 것 같습니다.

7. SSO(Single Sign-On)

제가 가장 기대했던 부분은 SSO 입니다. 읽는 도중에는 '이게 single sign-on을 제공하려는 목적이 아닌가?'라는 생각도 들었지만, 나름대로 논리를 확장해서 sso 서비스를 제공하는 시나리오를 도출했습니다.

<출처: http://code.google.com/apis/accounts/AuthForWebApps.html>

위 그림의 단계를 거치면 web application A는 사용자의 token을 얻고, 사용자는 구글 account에 인증을 받게 됩니다. 인증 정보가 세션 쿠키에 남겠죠.

그 다음에 다른 web application B로 사용자가 이동하는 경우를 생각해 봅시다. B는 당연히 사용자를 모르니까 구글을 통해 인증 받기를 원합니다. 사용자는 구글 account로 또다시 redirect 되죠. 이 때 구글이 사용자의 세션 쿠키를 보고 이미 인증되어다는 것을 확인한다면, 이것은 전형적인 single sign-on이 됩니다. 사용자는 정보 제공 여부만 선택해주면 되는 것이죠.

그런데!! 구글이 말하는 single sign-on을 보십시오.

If your web application supports users with multiple Google services accessed through Google Accounts, you may be looking to get a single authentication token good for all of the user's Google services. This is called 'single sign-on". Currently, Google AuthSub does not support a single-sign-on feature for third-party web applications. You will need to get a separate token for each service, and you will need to store and manage all tokens. However, we know that our development community wants such a feature. We are evaluating options over the next few months to add this support.

왜 하나의 인증 token을 발행하여 모든 구글 서비스에 사용하려고 할까요? 이 방법은 기술력도 없고, 보안에 대한 고려도 전혀 신경쓰지 않는 일부 SI 업체나 생각할 법한 땜빵식 sso입니다. 제가 밑줄 친 부분을 구글에서는 용납하지 않기 때문이 아닐까 추측해봅니다.

다시 생각해보니, 한 site가 여러 개의 google 서비스를 사용하기 위해 여러 개의 token을 발급하는 것에 대한 얘기더군요. 저는 사용자가 하나의 google 인증 토큰을 받아서 여러 site를 sso로 이동하는 것으로 상상했기 때문에 실수한 것 같습니다.

그렇게 보면 google이 sso를 제공한다는 건 좀 아닌 듯 보입니다. 제가 생각한 것은 google의 authentication을 적용한 site들이 사용자가 한번 로그인한 것으로 모두 이용할 수 있는 것이었는데, 이 스펙에서는 한 site가 여러 google 서비스를 sso로 이동하는 것을 의미하고 있네요.

제가 보기에는 Google의 인증 flow는 충분히 여러 site 간의 sso도 지원해줄 수 있습니다. 하지만 그 이야기에 대한 내용은 스펙에 언급되어 있지는 않은 것 같습니다.

휴. 시간이 많이 걸렸네요. 너무 비판적으로 읽기도 했고, 테스트를 통해서 실제 동작 과정을 살펴보지 않았기 때문에 제가 오해한 부분도 있을 겁니다. 빠른 시간 내에 테스트를 수행하여 내용을 갱신하겠습니다. 지적 부탁드립니다.

by S_H_Kim | 2006/07/05 22:56 | 트랙백(1) | 핑백(1) | 덧글(5)

트랙백 주소 : http://ayo79.egloos.com/tb/2541381
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from jsbaek at 2006/07/06 10:30

제목 : 승현님 Google Authentication AP..
&gt;&gt; 승현님 블로그 글... http://ayo79.egloos.com/2541381&gt;&gt;&gt;&gt; 2. 세션 token(무제한으로 사용할 수 있는 토......more

Linked at 구글 앱스(Google App.. at 2017/01/24 14:30

... 링크를 참고하세요.(약간 기술적인 내용이 있을 수 있습니다.) * Korean Identity Management(KIM) &#8211; Google Authentication 분석 part 1 : web-based application * 구글(Google) 계정 인증 API 공개 * 구글 계정 통합 착수, 가이아 엔진 시동거나? 구글 앱스의 미래 구글이 이 서비 ... more

Commented by heechul at 2006/07/06 09:56
늘 좋은 정보 감사드립니다 꾸우벅.
Commented by S_H_Kim at 2006/07/06 10:05
/heechul, 아, 서울대에서도 identity 관리 쪽을 연구하시는 분이 계시는군요. 반갑습니다. ID 관리 쪽에서도 의료 분야에 대한 관심이 많은 것 같습니다. EHR(Electronic Health Record)에는 반드시 ID 관리가 필요하죠. 관련 내용을 어느정도 수집했었는데 조만간 정리해서 올리겠습니다.

ps. 저도 꾸벅^^. heechul님 논문 읽어보겠습니다^^
Commented by heechul at 2006/07/06 12:59
아직은 뜬구름만 잡고 있답니다 ^^
앞으로도 많은 도움 받을께요 꾸우벅
Commented by stomita at 2006/07/06 15:10
Very interesting analysis about google account auth service. I found that Google should care about security much more. Thanks for your article.
Commented by S_H_Kim at 2006/07/06 15:52
/stomita, thanks for your interesting. I will make this article more regidly.

:         :

:

비공개 덧글

◀ 이전 페이지다음 페이지 ▶