오쓰(OAuth)란?··· 보안 전문가를 위한 가이드

CSO

분산형 PC네트워크가 태동한 이후 크랙하기에 유독 힘든 컴퓨터 보안기법 중 하나는 여러 컴퓨터에 걸쳐 원활한 SSO(Single Sign On) 액세스 경험을 제공하는 것이었다. 각 컴퓨터가 자신의 서비스와 콘텐츠를 이용하기 위해 관련 없는 로그인 계정이 필요하기 때문이다.

비록 전체 인터넷 전체에 실현되지는 않았을지라도, 이제는 하나의 로그인을 이용해 다수의 관련 없는 웹사이트들에 접근할 수 있다. 특정 한 장소에 로그인 하기 위해 비밀번호, 전화기, 디지털 인증서, 생체ID, 이중 인증(2FA), 다중 인증(MFA) SSO 솔루션 등을 사용하면 다른 장소에서도 하루 온 종일 다른 액세스 크리덴셜을 제공할 필요가 없다. 바로 오쓰(OAuth)덕분이다.



오쓰는 공개(open) 표준에 기반을 둔 인증 프로토콜, 도는 프레임워크로, 최초의 싱글 로그인 크리덴셜을 공유하지 않아도 관련 없는 서버와 서비스의 자산에 대한 접근을 인증할 수 있게 해준다. 인증 분야의 용어로 표현하자면 안전하고, 써드파티이며, 사용자 에이전트인 동시에 위임(Delegated) 인증 방식이라고 표기될 수 있다.

태동부터 트위터, 구글 등이 강력히 지원하고 나섰던 오쓰는 2010년 RFC 5849 공개 표준으로 등장했다. 그리고 곧장 광범위하게 보급됐다. 2년 여 동안 대대적인 버전 변경을 거친 후, 2012년 RFC 6749로 오쓰 2.01 버전이 출시됐다. 버전 2.0은 아래에서 다룰 여러 이유로 많은 비판을 받았음에도 불구하고 더 큰 인기를 끌었다.

지금은 아마존, 페이스북, 인스타그램, 링크드인, 마이크로소프트, 넷플릭스, 페이팔 및 기타 회사들이 이를 도입해 사용하고 있다.

오쓰를 간단한 사례를 들어 설명해보자. 특정 웹사이트에 방문해 로그인 하려 할 때, 해당 웹사이트는 다른 하나 이상의 웹사이트/서비스의 로그인을 이용해 로그인할 기회를 준다. 다른 웹사이트에 링크된 버튼을 클릭하면, 이 웹사이트가 사용자를 인증한다. 그러면 최초 로그인 하려 했던 웹사이트가 다른 웹사이트의 승인을 사용, 사용자를 로그인시킨다.

또 다른 사용 사례도 있다. 사용자가 이메일로 다른 사용자에게 클라우드에 저장한 파일을 전송하는 경우이다. 여기에서 클라우드 스토리지와 이메일 시스템은 서로 관련이 없는 것들이다. 구글 지메일을 이용해 마이크로소프트 원드라이브 파일을 공유하는 사례가 여기에 해당된다.

최종 사용자가 이메일에 파일을 첨부하고, 브라우저에서 첨부할 파일을 선택할 때 이면에서 오쓰가 작동한다. 이메일 시스템은오쓰를 통해 사용자가 파일 스토리지 시스템에 별도 로그인 할 필요 없이 보호된 파일에 접근할 수 있도록 승인한다. 오쓰 2.0 FRC에 따르면, 최종 사용자가 써드파티 프린팅 서비스를 이용해 관련 없는 웹 서버에 저장된 사진 파일을 인쇄하는 사례도 포함된다.

어느 사례이든 최종 사용자의 트랜젝션 1회에 2개 이상의 서비스를 사용한다. 최종 사용자는 매번 로그인을 할 필요가 없게 된 것을 반길 것이다. 오쓰가 작동하기 위해서는 최종 사용자의 클라이언트 소프트웨어(예, 브라우저), 관련된 서비스 및 인증 공급업체가 적절한 OAuth 버전(1.0 또는 2.0)을 지원해야 한다.

오쓰 작동 원리
오쓰를 이해하려면, 어느 사례에서나 항상 2개의 관련 없는 사이트나 서비스가 사용자나 소프트웨어를 대신한다는 점을 기억하는 것이 도움이 된다.

또 오쓰는 직접적인 인증(Authentication)이 아닌, 인가(승인, Authorization)와 관련이 있다는 점을 명심하는 것이 좋다. 인증은 사용자/대상이 비밀번호나 기타 고유의 요소를 제공해 제시한 ID의 실제 소유주임을 증명하는 프로세스다. 반면 인가(승인)는 인증을 성공적으로 완료한 후 (많은 경우 다른 장소에서)대상이 리소스에 액세스 할 수 있도록 허락하는 프로세스다. 오쓰를 공개 인증 표준으로 생각하는 사람이 많다. 그러나 공개 인가(승인) 표준으로 생각하는 것이 이해에 도움을 준다.

초기 도입자 중 한 명은 오쓰를 자동차 발레 파킹 키에 비유했다. 잠시 차를 운전해 주차할 때 사용할 수 있지만, 일반 키처럼 제약 없이 사용하는 것은 불가능한 키를 의미한다. 짧은 거리는 운전할 수 있지만, 트렁크나 글로브 박스를 열 수 없다. 즉 오쓰는 성공적으로 인증을 제공했던 인증 공급업체를 통해 사용자에게 다른 웹사이트/서비스에 제약 없이 액세스 해 리소스를 이용할 수 있는 액세스 인증 토큰을 제공할 뿐이다.

덧붙이면, 오쓰 2.0은 1.0 버전과 달리 프로토콜이 아닌 프레임워크다. 모든 자동차 제조업체들이 발레 키를 요청하고, 수령해 사용하는 방식, 발레 키 형태에 합의하는 것과 유사하다. 발레 키와 일반 키의 차이점은 각 제조업체에 달려 있다. 현실에서 발레 파킹 담당자와 차량 소유자는 작동 방식을 신경 쓰지 않는다. 키를 넘겨줬을 때 이상 없이 작동만 하면 된다. 그것만 신경 쓴다.

오쓰의 단계
사용자가 이미 특정 웹사이트나 서비스에 로그인 했다고 가정하자. 참고로 오쓰는 HTTPS만 작동한다. 사용자는 이후 다른 관련 없는 사이트나 서비스에 액세스 하기 위한 트랜젝션을 개시한다. 그러면 다음 단계가 발생한다.

1. 첫 번째 웹사이트가 사용자를 대신해 두 번째 웹사이트에 접속한다. 오쓰를 사용하고, 사용자의 확인된 ID를 제공한다.


2. 두 번째 사이트는 해당 트랜젝션 및 관여 당사자에 고유한 1회성 암호와 1회성 토큰을 생성한다.

3. 첫 번째 사이트는 이 토큰과 암호를 사용자의 클라이언트 소프트웨어에 제공한다.

4. 클라이언트 소프트웨어는 요청 토큰과 암호를 인증(인가) 공급업체에 제시한다(두 번째 사이트 또는 다른 사이트나 서비스).

5. 인증(인가) 공급업체에 인증이 되어 있지 않다면, 클라이언트가 인증을 요청할 것이다. 인증 후, 클라이언트는 두 번째 웹사이트에 인증 트랜젝션 승인을 요청한다.

6. 사용자 또는 소프트웨어는 첫 번째 웹사이트에서 특정 트랜젝션을 승인한다.

7. 그리고 사용자에게 승인된 액세스 토큰이 제공된다(더 이상은 요청 토큰이 아님).

8. 사용자는 첫 번째 웹사이트에 승인된 액세스 토큰을 제공한다.

9. 첫 번째 웹사이트는 사용자를 대신, 인증에 대한 증명인 액세스 토큰을 두 번째 웹사이트에 제공한다.

10. 두 번째 웹사이트는 사용자를 대신, 첫 번째 웹사이트가 사이트에 엑세스 할 수 있도록 허락한다.

11. 사용자는 트랜젝션이 성공적으로 완료된 것을 확인한다.

12. OAuth는 최종 사용자를 대신해 이런 방식으로 작동하는 첫 번째 인증/인가(승인) 시스템은 아니다. 유사하게 작동하는 인증 시스템이 많다. 오쓰의 차별점은 여러 웹에서 작동을 하고, 널리 도입되었다는 점이다. 과거 다른 시스템과 달리, (여러 이유 덕분에)도입률을 높이는 데 성공했다.

아주 간단하지는 않지만, 웹 개발자들이 관련된 트랜젝션을 즉시 이해할 수 있을 것으로 것이다. 몇 시간 또는 하루 이내에 오쓰를 지원하는 웹사이트를 구축할 수 있다(과거 구축 경험이 있다면 더 빨리 완성할 것이다).

즉 약간의 노력만 투자하면, 인증된 웹사이트 액세스를 수백 만 사용자에 추가 확대 적용할 수 있다. 웹사이트에 확장 능력을 갖춘 고유 인증 시스템을 포함시킬 필요가 없다. 여기 링크에서 개별 HTTP 트랜젝션 패킷의 예제를 확인할 수 있다.

오쓰에 대한 비판과 솔루션
완벽하면서도 보편적인 인터넷 인증 표준은 존재하지 않는다. 오쓰는 버전 2.0이 1.0과 크게 달라지면서 비판을 받았다. 많은 측면에서 오쓰 2.0이 덜 안전하고, 더 복잡하다. 또 1.0보다 이해가 어렵다. 2.0 버전 개발측은 사이트와 장치 간 유연성과 상호운영성을 높이는 데 초점을 맞춰 오쓰 2.0 버전을 개발했다. 또 1.0 버전에는 없었던 '토큰 만료' 개념을 도입했다. 의도가 무엇이든, 최초 개발자와 지원자 가운데 상당수가 2.0 버전을 지원하지 않았다.

바뀐 부분이 너무 많아, 2.0 버전과 1.0 버전이 서로 호환되지 않는다. 구현 방식에 따라, 같은 2.0 버전이라도 서로 호환되지 않는 경우도 있다. 하지만 어느 경우이든 웹사이트에서 1.0 및 2.0 버전을 모두 지원할 수 있다. 물론 2.0 개발측은 2.0 버전이 1.0 버전을 완전히 대체해 도입되도록 만들 계획이었다.

오쓰 2.0에 대한 가장 큰 비판 중 하나는, 이 표준이 암호화와 서명, 클라이언트 확인, 채널 바인딩(특정 세션이나 트랜젝션을 특정 클라이언트 및 서버와 연동)을 직접 규정 또는 지원하지 않는다는 점이다. 구현 당사자가 TLS(Transport Layer Security) 같은 외부 보호 프로토콜을 사용해 이런 기능을 제공해야 한다.

TLS는 모든 보호 기능을 제공한다. 그러나 이를 사용할지 여부는 구현 당사자에 달려 있다. 코더와 사용자는 TLS 보호 아래 오쓰가 실행되는지 확인해야 한다. 개발자는 TLS 사용을 강제하는 코드를 구현할 수 있다. 사용자는 인증 크리덴셜 입력을 요청 받을 때마다 TLS가 사용되고 있는지 확인해야 한다.

보안 바인딩 기능이 내장되어 있지 않기 때문에, 악성 웹사이트가 사용자가 인증(인가) 공급업체에 자신을 인증하는 프로세스 동안 사용자의 적법한 크리덴셜을 '피싱' 할 수 있다.

사용자가 첫 번째 서비스를 사용하면서, 두 번째 서비스에 오쓰 트랜젝션을 강제하는 기능을 선택했다고 가정하자. 첫 번째 웹사이트가 사용자 인증이 자주 이뤄지는 두 번째 웹사이트를 위조할 수 있다. 그러면 악성 웹사이트가 사용자의 인증 크리덴셜을 수집, 오쓰 트랜젝션이 성공적으로 완료된 것처럼 반응할 수 있다.

이론적인 위협이 아니다. 2017년 2분기, 100만 개의 구글 계정이 피싱 당한 사고가 있었다. 방어책은 사용자가 적법한 두 번째 웹사이트 도메인에서 크리덴셜을 요청 받았을 때 이를 입력하는 것이다. 의심스러운 첫 번째 웹사이트를 피하기 위해서다. 아직 완벽하게 안전하며, 모든 웹사이트에서 작동하는, 그리고 보편적으로 수용된 SSO는 존재하지 않는다. 그러나 오쓰는 여기게 한 발 더 가까이 접근한 표준이다.

* Roger A. Grimes는 2005년부터 보안 칼럼니스트로 활동하고 있다. ciokr@idg.co.kr