Security in OAuth

Posted in .NET Framework // Posted at 2013. 5. 29. 16:59
728x90

표준 인증체계를 정의하는 OAuth에 적용된 보안 개념들은 OAuth를 사용하지 않더라도 인터넷과 같은 열린 공간에서의 통신에서 보안을 강화하는 아키텍처로써 가치가 있다.

 

분산 시스템간 통신 시, 이러한 개념을 적절히 접목하면 보안성이 잘 갖춰진 시스템을 만들 수 있을 것이다.

 

먼저 시스템간의 통신에서 보안이란 대략 다음과 같은 요소들로 정리할 수 있겠다.

 

1. 기밀유지 (암호화)

보안의 가장 기본적인 요소로 데이터를 읽지 못하게 만들어야 한다.

공격자가 통신 패킷을 중간에 가로채서 보더라도 데이터를 읽을 수 없는 상태로 만들어야 하는데 이를 위해 각종 암호화 기법을 적용하게 된다.

 

2. 신원확인 (자격증명)

허가된 클라이언트만이 통신을 허용할 수 있도록 해야 하는데 이를 위해 클라이언트는 자신의 자격증명을 제출하도록 한다. 보통 ID/PW를 제출하기도 하고 클라이언트 인증서, 임의의 토근 등이 사용되기도 한다.

 

3. 변조 방지 (디지털서명)

공격자가 통신 패킷을 중간에 가로채서 변경하지 못하도록 해야 한다.

서버의 입장에서는 요청이 중간에 변조되지 않았는지를 확인 해야 하는데, 이를 위해 전송 데이터의 해시 값을 구하고 이 해시 값을 클라이언트의 비밀키로 암호화하도록 한다.

이를 디지털 서명이라고 하는데 변조 방지 뿐만 아니라 클라이언트가 자신이 보낸 것이 아니라고 하는 부인방지도 효과도 있다.

 

4. 재생 방지

일반적인 보안 시나리오에서 간과되기 쉬운 부분인데, 분산 환경에서의 통신에서는 특별히 주의해서 방어해야 하는 요소이다. 앞의 1,2,3 의 보안 요소들이 잘 갖춰져 있다하더라도 공격자가 중간에서 패킷을 가로채 그대로 다시 서버로 전송할 경우 이를 거부하도록 해야 한다.

 

OAuth 프로토콜은 이러한 보안 개념들을 적절히 잘 접목한 안전한 인증시스템이라 할 수 있다.

 

OAuth를 통한 인증 과정에서는 실제로 기밀유지보다는 변조방지와 재생방지에 무게 중심이 있다고 하겠다.

OAuth 인증 과정에서는 비밀번호라던가 주민번호와 같은 기밀을 유지해야 하는 민감한 데이터가 포함되지 않기 때문에 기밀유지를 위한 과도한 암호화는 불필요하다. 다만 인증된 클라이언트에 의한 유효한 요청인지가 더욱 중요하다는 것이다.

(OAuth 인증 과정 중, 사용자가 ID/PW를 입력해서 로그인 하는 과정이 있지만 이 부분은 OAuth 인증 과정이라기 보다는 사용자와 서비스 프로바이더간 보안 구간이라고 하겠다.

또한 OAuth 인증 과정을 모두 완료한 후 액세스 토큰으로 보호된 자원에 접근하는 경우에 기밀 데이터가 있을 경우 htts와 같은 별도의 암호화 장치를 둬야 한다. 이 구간 역시 OAuth 인증 과정과는 별도로 이해하기 바란다)

 

OAuth에서는 데이터의 변조 방지를 위해 해시 값과 디지털 서명을 사용한다.

이때 Consumer Secret 이 비밀키로 사용되며 HMAC-SHA1와 같은 해싱 알고리즘이 적용된다.

(참고로 OAuth 2.0의 경우, HTTPS를 사용하게 됨으로써 HAMC를 사용하지 않아도 된다)

 

그리고 재생 방지를 위해서는 Timestamp와 Nonce가 사용되는데,

Nonce는 모든 요청에 유일함이 보장되어야 하는 (클라이언트에서 생성하는) 임의의 문자열인데,

재생 공격시 이 값을 체크해서 (이미 이전 요청에 사용된 Nonce일 경우) 요청을 거부하게 된다.

 

그렇다면 Nonce의 유일성을 체크해야 하는 서버의 입장에서는 모든 요청의 Nonce 값을 보관하고 있어야 하는 부담이 있는데, 이는 Timestamp 체크로 부담을 제거하게 된다.

 

OAuth 인증 과정에서 포함되는 Timestamp는 요청을 생성한 시점의 타임스탬프 값으로써 1970년 1월 1일 00:00:00(GMT) 이후의 시간을 초로 환산한 숫자 값인데 이 값의 유효 범위를 지정해 기간이 경과한 요청은 거부하도록 한다.

 

즉 Nonce의 유일성 체크 이전에 Timestamp에 의한 유효 시간 체크를 먼저 함으로써 서버 입장에서는 유효시간 내의 Nonce값만을 관리하면 되는 것이다.

 

마지막으로 OAuth 인증 과정을 모두 마치면 클라이언트는 사용자의 인증을 대신하게 되는데 이때 Authorization Header라는 HTTP 헤더 값을 자격증명으로 제출하게 되는 셈이다.

 

이러한 OAuth 인증과정에 적용된 보안 개념들은 다른 어플리케이션을 개발할 때에도 참고하기에 충분한 가치가 있다고 하겠다.