2017.08.18

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

Roger A. Grimes | 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를 제공한다.


2017.08.18

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

Roger A. Grimes | 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를 제공한다.


X