1. 개요

Web Service 보안과 같은 주제를 다루다 보면 항상 부딪히게 되는 것이 바로 SAML, OAuth 등과 같은 인증 부분이라고 할 수 있다. 보통 이러한 메시지의 교환에는 크게 3가지 보안 영역이 다루어진다고 볼 수 있다.

• 데이터 무결성
• 데이터 기밀성
• AAA (인증/인가/감사)

이 중 데이터 무결성이나 데이터 기밀성은 전자 서명, 데이터 암호화, SSL 등과 같은 채널 암호화 등의 기술을 통해서 구현된다. 반면 SAML이나 OAuth 등은 인증 및 인가와 관련된 프로토콜이라고 할 수 있다.

2. SAML

SAML은 기본적으로 Identity Federation의 개념에서부터 시작한다. (자세한 설명은 SAML 개념 문서 참조) Identity Federation은 서로 다른 기업 혹은 도메인 간의 SSO 연계로부터 출발한다. 예를 들어 A 회사에 다니는 어떤 사람이 출장을 가려고 하는데 A 회사는 B 여행사와 파트너십 관게를 맺고 모든 호텔 및 비행기 예약은 B 여행사가 대행하는 시나리오를 생각해 볼 수 있다. 이 때 A 회사 직원은 A 회사의 사이트 www.company.com에 인증을 하면 별도의 로그인 없이 B 여행사의 예약 사이트 www.booking.com에 접근이 가능하다고 하자. 이 경우 A 회사는 사용자의 인증을 담당하는 주체가 되고, B 여행사는 A 회사에서 인증한 사용자를 신뢰하고 예약 서비스를 제공하는 주체가 된다. 여기서 A 회사는 사용자의 인증 및 인증 여부 결과 제공을 담당하므로 Identity Provider (IdP)라 불리고, B 여행사는 A회사에서 인증한 사용자에게 예약 서비스를 제공하므로 Service Provider (SP)라 불린다.

위의 시나리오를 바탕으로 다음과 같은 A 회사 직원의 호텔 및 비행기 예약 Workflow를 생각해 볼 수 있다.

1. www.company.com에 로그인
2. www.company.com 내의 출장 예약 서비스 링크 클릭
3. www.booking.com 사이트로 redirection
4. www.booking.com에서 해당 사용자가 www.company.com에서 인증되었는지의 여부 체크
5. 인증된 사용자일 경우 예약 서비스 화면을 표시

위의 Workflow는 IdP (www.company.com)에서 시작되었으므로 IdP-initiated SSO라고 불린다. 이와 다르게 SP에서부터 시작하는 SP-initiated SSO도 생각할 수 있다.

1. 북마크를 이용해 www.booking.com 사이트의 예약 서비스 페이지에 접근
2. www.booking.com에서는 해당 사용자가 아직 로그인하지 않았으므로 인증 정보 요청과 함께 www.company.com 사이트로 redirection
3. www.company.com에서 사용자 인증 (로그인)
4. 인증 결과와 함께 www.booking.com으로 redirection
5. www.booking.com의 예약 서비스 페이지에서 사용자 인증 여부 체크 후 페이지 표시

여기서 www.company.com과 www.booking.com은 서로 인증 요청 및 결과 정보를 주고 받아야 함을 알 수 있다. 이러한 인증 관련 정보 교환에 쓰이는 프로토콜이 바로 SAML이다. SAML은 다양한 방법을 통하여 인증 정보를 교환할 수 있는 창구를 제공한다.

3. OAuth

OAuth는 SAML과 달리 Service Consumer와 Service Provider라는 개념을 담고 있다. 예를 들어 Facebook을 생각해 보자. Facebook은 자신이 관리하고 있는 사용자들의 Social Network 정보를 API로 제공하고 개발자들은 이러한 API를 사용하여 다양한 애플리케이션을 만들 수 있다. 예를 들어 어떤 사람이 Facebook과 연동되는 웹 메신저 애플리케이션을 개발했는데 이 메신저 프로그램에서는 Facebook의 친구 리스트를 API를 통해 불러와 자신의 대화 상대 목록에 저장할 수 있다. 따라서, 이 시나리오에서는 3가지 Tier가 존재함을 알 수 있다.

사용자 -- 메신저 -- Facebook

이 경우, 예상되는 사용자 인증과 관련된 요구 사항들은 다음과 같다.

• Facebook API는 메신저가 API를 호출했을 때, 파라미터로 넘어오는 사용자가 Facebook에 인증된 사용자인지, 그리고 해당 정보에 접근할 수 있는 권한을 가진 사용자인지를 검사해야 한다. (사용자 인증/인가)
• 메신저 프로그램은 사용자의 Facebook ID 및 비밀번호를 알 수 없어야 한다.

이 두 가지 요건을 만족시키기 위해서 먼저 사용자 인증은 Facebook이 담당하게 된다. 예상되는 시나리오는 아래와 같다.

1. 사용자가 메신저 프로그램을 사용하다가 페이스북의 친구 리스트를 가져와야 할 경우, 먼저 웹 메신저는 backend channel을 열어 Facebook에게 request token을 요청한다.
2. 웹 메신저는 사용자를 Facebook 인증 페이지로 redirection 시킨다. 이 때 웹 메신저는 인증 후 되돌아와야 할 callback url 및 Facebook으로부터 발급받은 request token 등의 정보를 파라미터로 넘긴다.
3. 사용자는 Facebook 인증 페이지에 자신의 ID와 패스워드를 입력하고 로그인을 한다. Facebook 인증 페이지는 인증이 성공하면 사용자를 callback url로 redirection 시킨다.
4. 메신저는 다시 backend channel을 통해 Facebook에게 access token을 요청하여 발급받는다.
5. 메신저는 이후의 모든 Facebook API 호출에 발급받은 access token을 넘기고 Facebook에서는 access token이 폐기될 때까지 사용자 및 애플리케이션이 인증된 것으로 간주하고 메신저의 API 호출을 정당한 것으로 판단하여 결과를 리턴한다.

위의 프로세스를 그림으로 표현하면 다음과 같다. (출처: http://www.oauth.net/)

(위 그림은 OAuth 1.0 버전으로 현재 OAuth 2.0이 작업 진행 중이다.)

4. SAML과 OAuth의 비교

SAML은 멀티 도메인 간의 SSO 성격이 강하다. 위의 예제에서처럼 www.company.com에서 인증된 사용자라면 www.booking.com에서는 www.company.com을 신뢰하므로, 이 사이트에서 인증된 사용자 역시 신뢰하는 사용자로 판단하여 인증 처리를 해 주는 것이다. 그런데 여기서는 www.booking.com과 www.company.com 간에는 아무런 상호작용이 없을 수도 있다. 즉 Identity만 서로 공유할 뿐 전혀 독립된 개체로서 서로 다른 유형의 서비스를 사용자에게 제공하고 있는 것이다. 즉 사용자와 www.company.com, 혹은 사용자와 www.booking.com 사이에 직접적인 관계가 맺어지는 것이다.

반면 OAuth에서는 사용자 -- 메신저 -- Facebook 이렇게 3단계의 dependency가 존재하게 된다. 사용자는 Facebook에 직접 접근하거나 사용하는 것이 아니다. 단지 메신저 애플리케이션을 이용하다 보니, Facebook에서 제공하는 서비스를 메신저가 제공받아야 하는 것이다.

이렇게 하나의 애플리케이션(Service Consumer)이 또 다른 애플리케이션(Service Provider)를 사용하는 관계가 생기다 보니 Service Provider 입장에서는 Service Consumer를 인증/인가해야 하는 필요성이 생기게 된다. 즉, Service Consumer가 요청하는 사용자 정보가 있다면 이 사용자가 인증/인가된 사용자인지를 검사하는 것뿐만 아니라, Service Consumer 자체가 인증/인가된 애플리케이션인지도 확인해야 하는 것이다. 이러한 애플리케이션 인증의 과정은 access token이 발급되는 시점에 보통 이루어진다.

물론 애플리케이션 간의 서비스 공급/소비 관계에서도 SAML을 사용할 수 있다. 하지만 SAML 자체가 애플리케이션에 대한 인증 내용을 포함하고 있지는 않다. 따라서, SAML이 좀 더 범용적인 측면의 사용자 SSO를 의미한다면, OAuth는 Service Consumer - Provider에 특화된 사용자 및 애플리케이션 인증 프로토콜이라고 말할 수 있다.

5. 기타

2009년에 본인이 일하고 있던 모 프로잭트에서 OAuth 프로토콜을 프로젝트 요구사항에 맞게 변형하여 사용자 및 애플리케이션 인증을 처리하는 프레임워크를 만들고 있었다. 그런데 갑자기 OAuth의 Security hole이 발견되어 구글 등이 모두 OAuth 서비스를 폐쇄하는 사태가 일어났었다. 그만큼 OAuth는 아직 미성숙한 단계에 있고 현재 많은 욕을 먹고 있는 것으로 보여진다. 반면 SAML은 많은 곳에서 이미 상용화가 되어 있고, 활용되고 있다.

어찌 되었든, OAuth 2.0이 릴리즈되면 좀 더 탄탄한 보안 체계를 갖춘 스펙이 되기를 기대해본다.