인증은 리소스에 대한 액세스를 승인하기 위해 어떤 방법으로 사용자를 식별하는 것을 의미한다. 여기서 논하는 프로토콜은 SAML 2.0, 오픈ID 커넥트(OIDC), 오쓰(OAuth)2다. 오쓰2는 인증 프로토콜은 아니지만 사용자가 페이스북, 아마존과 같은 소셜 서비스를 통해 로그인할 수 있도록 하는 등의 사용례에서 워낙 광범위하게 사용되고 있어 포함했다.
ID, 인증, 승인 프로토콜
ID(Identity), 인증, 승인(Authorization) 이 세 가지 프로토콜은 기능 측면에서 상호 겹치는 부분이 많다.- ID 프로토콜은 사용자의 영구 식별자, 전화번호, 이메일 주소와 같이 시스템에서 사용자를 장기적으로 식별해서 인증하고 리소스 액세스를 승인하는 데 사용할 수 있는 정보를 제공한다. 가장 잘 알려진 사례는 SAML과 OIDC다.
- 인증 프로토콜에 반드시 개인 식별자가 포함되지는 않는다. 예를 들어 커베로스(Kerberos) 시스템은 일시적인 익명 키의 교환을 기반으로 하는 시스템인데, 키 자체에는 식별 데이터가 포함되지 않는다.
- 오쓰2, UMA와 같은 승인 프로토콜은 리소스 소유자에게 인증 정보 공유를 요구하지 않으면서 보호되는 리소스를 획득하기 위한 수단을 제공한다. 양방향 사용자 동의는 이러한 프로토콜의 중요한 측면이다. 오쓰2 프로토콜은 ID와 인증에 흔히 사용되며, 이때 식별자와 같이 오쓰2 프로세스에 반환되는 사용자 데이터를 사용한다.
ID 프로토콜은 유연함 덕분에 정부, 기업, 소비자 영역에서 웹, 모바일 앱, 데스크톱 애플리케이션에 걸쳐 최선의 인증 방법으로 확산하고 있다. 앞서 언급한 모든 프로토콜은 싱글사인온(SSO) 애플리케이션에 사용할 수 있다. 단, 오쓰2의 주의점을 고려해야 한다.
탈중앙화 ID(DID)
DID(Decentralized Identities, 탈중앙화 ID) 또는 자주적 ID(Self–Sovereign Identities)에도 주목할 필요가 있다. DID는 사용자가 모바일 디바이스에 저장하는 ID 속성에 의존하는 ID 시스템이며 분산 원장 기술을 사용해 해당 속성의 소유를 입증한다. 정립된 기존 표준 ID 프로토콜에 이러한 시스템을 통합하기 위한 제안이 현재 진행 중이지만, 현재 상황은 복잡한 맞춤 프로토콜(예를 들어 uPort)이다. 따라서 현시점에서 범용 ID나 인증을 위해 DID 사용은 권장하기 어렵다. 다만 아보코 시큐어(Avoco Secure)와 같은 업체가 제공하는 오케스트레이션 API는 표준 프로토콜로의 변환을 통해 이 문제를 극복할 수도 있다.
제안된 프로토콜의 사용례
1. IoT 디바이스와 관련 앱
이 사용례에서 앱은 디지털 ID를 사용해 앱 자체 및 앱과 관련 클라우드 리소스에 대한 액세스를 통제한다(예를 들어 아마존 알렉사와 같은 IoT 디바이스). 알렉사는 계정을 생성한 다음, 데이터 저장소의 데이터를 공유하는 데 사용된다.- 프로토콜 선택: OIDC / OAuth2
리소스 액세스를 위한 단순한 승인 사례이고, 특히 키보드나 화면이 없는 스마트 디바이스를 사용한 비교적 간단한 경우에 해당하므로 오쓰2가 적당하다.
2. 소비자 ID 공급업체(IdP)
이 사용례의 예를 들면 신뢰 당사자(Relying Parties, RP)에 ID 데이터를 제공해야 하는 온라인 은행, 정부 서비스가 있다. IdP( identity provider)는 고객신원확인(Know-Your-Customer, KYC) 프로세스를 통해 검증된 사용자의 속성과 함께 민감한 데이터를 보관하며 표준 수준의 ID를 제공한다. 승인된 ID만 IdP에 액세스할 수 있다.- 프로토콜 선택: SAML, OIDC
강력한 보안이 필요한 경우, 일반적으로 SAML을 선택하는 것이 좋다. RP와 IdP 사이에서 이뤄지는 교환의 모든 부분에 양 당사자의 디지털 서명과 검증이 가능하기 때문이다. 이를 통해 각 당사자는 대화하는 상대방의 신원이 가짜가 아님을 확신할 수 있다. 또한 IdP의 주장(assertion)은 암호화가 가능하므로 HTTPS 외에 사용자 데이터에 대한 공격자의 접근을 차단하는 부가적인 수단이 될 수 있다. 보안을 더 강화하려면 서명 및 암호화 키를 주기적으로 순환하면 된다.
OIDC를 이와 동등한 보안 수준으로 끌어올리기 위해서는 오픈 뱅킹(Open Banking) 확장의 경우와 같은 부가적인 암호화 키가 필요한데, 이를 설정하고 유지하는 과정이 다소 부담스러울 수 있다. 그러나 OIDC는 SAML에 비해 모바일 앱에서 더 간편히 사용할 수 있으며 JSON 사용에 따른 장점도 있다.
3. 헬스 데이터 공유 포털
이 사용례에서 포털은 극히 민감한 헬스 데이터에 대한 여러 방식의 데이터 공유를 지원해야 한다.- 프로토콜 선택: OIDC, UMA
다양한 형태의 디바이스가 사용될 가능성이 높고 일부는 브라우저 기반이 아닐 수도 있는 만큼(이 경우 SAML은 배제됨) OIDC가 더 나은 선택이다. OIDC와 연결된, 기본 제공되는 동의는 데이터 공유의 개인정보보호 측면을 강화해준다. 또한 서명과 암호화를 통해 보안을 강화해서 민감한 데이터를 취급하는 데 필요한 수준의 요구사항을 충분히 충족할 수 있다.
4. 시스템이 폭넓은 ID 서비스 생태계 내의 여러 서비스 공급업체 지원
이 사용례의 예를 들면 보험 서비스 컨소시엄이 있다. 시스템은 사용자에게 기존 ID 계정을 사용해 서비스에 연결하는 방법을 제공해야 한다. 또한 사용자가 필요에 따라 부가적인 데이터를 추가해야 할 수도 있다.- 프로토콜 선택: OIDC, OAuth2, SAML
이 사례의 경우 이미 다양한 IdP에 계정이 있는 사용자가 더 간편히 이용할 수 있도록 사용자에게 IdP 선택권을 제공해야 한다. 예를 들어 정부가 발급한 ID가 있는 사용자도 있고, 페이팔 또는 아마존 계정을 보유한 사용자도 있을 것이다.
다양한 계정 유형에 대한 선택권을 제공하면 사용자는 온라인 등록 및 확인 프로세스를 거칠 필요 없이 손쉽게 각 보험 서비스를 이용할 수 있다. 따라서 각 RP는 복수의 프로토콜을 지원해야 하고 한 공급업체의 ID가 필요한 모든 클레임 또는 속성을 제공하지 않는 상황에도 대처해야 한다. 해결책은 RP가 요구하는 프로토콜로 변환할 수 있고 필요한 모든 속성을 수집하는 ID 오케스트레이션 브로커(orchestration broker) 또는 프록시 서비스(proxy service)를 사용하는 것이다. editor@itworld.co.kr