Architecture Decision Record
← 의사결정 기록 예시

아키텍처 의사결정 기록: 인증과 인가 옵션

웹 애플리케이션의 인증과 인가는 애플리케이션과 서비스에 대한 접근을 보호하는 데 중요한 두 개념입니다. 둘 다 사용자의 신원과 권한이 부여되는 방식을 다루지만 서로 다른 측면에 초점을 맞춥니다:

  • **인증(Authentication)**은 사용자나 시스템의 신원을 확인하는 과정입니다.
  • **인가(Authorization)**는 인증된 사용자나 시스템이 어떤 리소스나 동작에 접근할 수 있는지를 결정하는 과정입니다.

이제 현대 웹 애플리케이션에서 인증과 인가를 관리하는 데 흔히 쓰이는, 언급하신 구체적인 프로토콜과 기술을 자세히 살펴보겠습니다.

1. OAuth (Open Authorization)

OAuth는 인가를 위한 개방형 표준입니다. 사용자가 자격 증명을 공유하지 않고도 서드파티 애플리케이션에 자신의 리소스에 대한 제한된 접근 권한을 부여할 수 있게 해 줍니다. 핵심 아이디어는 위임된 접근입니다. OAuth는 사용자가 서드파티에 사용자 이름과 비밀번호를 직접 제공하지 않고 서드파티 서비스에 로그인할 수 있는 상황(예: Google로 로그인)에서 자주 사용됩니다.

  • 흐름: OAuth는 보통 토큰 기반 흐름을 따르며, 인가 서버가 서드파티 애플리케이션에 액세스 토큰을 발급합니다. 이 토큰은 사용자의 권한을 나타내며, 애플리케이션은 이를 사용하여 API에서 사용자의 데이터나 리소스에 접근합니다.
  • 예시: 사용자가 Google 계정으로 서드파티 앱에 로그인합니다. Google은 사용자의 신원을 확인한 다음, 서드파티 앱이 일부 Google 데이터(예: Google 캘린더)에 접근할 수 있도록 토큰을 부여합니다.

OAuth는 인증을 직접 처리하지 않으며, 접근 권한을 부여하는 것입니다. 인증을 위해서는 OAuth를 OpenID Connect 같은 다른 프로토콜과 함께 쓰는 경우가 많습니다.

2. OpenID Connect (OIDC)

**OpenID Connect (OIDC)**는 OAuth 2.0 위에 구축된 신원 계층으로, OAuth의 인가 기능에 인증을 더합니다. 본질적으로 OpenID Connect는 OAuth를 확장하여 사용자 인증을 처리하고, 애플리케이션이 사용자의 신원을 확인하는 표준화된 방법을 제공합니다.

  • 흐름: 사용자가 OpenID Connect로 로그인하면 서드파티 애플리케이션은 (OAuth 액세스 토큰과 더불어) ID 토큰을 요청합니다. ID 토큰에는 사용자에 대한 정보(사용자 이름, 이메일 및 기타 클레임 등)가 들어 있습니다. 이를 통해 애플리케이션은 사용자가 누구이며 인증되었는지 알 수 있습니다.
  • 예시: Google 계정(Google이 OpenID Connect 제공자)으로 Slack 같은 서비스에 로그인할 때는 OpenID Connect를 통한 인증이 이루어지고, OAuth는 Google 리소스에 대한 접근을 관리합니다.

OIDC는 서드파티 앱이 사용자를 인증하기 쉽게 하면서도 해당 앱이 접근할 수 있는 리소스에 대한 세밀한 제어를 허용합니다.

3. SAML (Security Assertion Markup Language)

SAML은 당사자 간에 인증 및 인가 데이터를 교환하는 데 사용되는, 더 오래된 XML 기반 표준이며 특히 싱글 사인온(SSO) 시나리오에서 쓰입니다. 주로 기업 환경에서 사용자가 한 번 인증하고 자격 증명을 다시 입력하지 않고도 여러 애플리케이션에 접근할 수 있게 하는 데 쓰입니다.

  • 흐름: 사용자가 먼저 아이덴티티 제공자(IdP)로 인증합니다. IdP는 사용자의 신원과 관련 속성을 포함하는 서명된 SAML 어설션을 생성합니다. 어설션은 서비스 제공자(SP)로 전송되고, SP는 이를 사용하여 애플리케이션 접근을 인가합니다.
  • 예시: 직원이 사내 포털(IdP)에 로그인하면 자격 증명을 다시 입력하지 않고도 이메일, CRM 등 다른 시스템에 자동으로 로그인됩니다. 인증 과정은 IdP가 보내는 SAML 어설션에 기반합니다.

SAML은 기업 SSO 솔루션에서 흔히 사용되며 기업 환경의 웹 애플리케이션에 잘 작동하지만, OAuth/OIDC에 비해 모바일 친화적이지 않습니다.

4. WS-Federation (Web Services Federation)

WS-Federation은 특히 Microsoft 기반 기업 환경에서 **싱글 사인온(SSO)**에 쓰이는 또 다른 프로토콜입니다. WS-*(웹 서비스) 명세 계열의 일부이며 서로 다른 보안 도메인(예: 서로 다른 조직 사이 또는 서로 다른 서비스 사이)에 걸친 신원 연합을 가능하게 합니다.

  • 흐름: WS-Federation은 **신뢰할 수 있는 아이덴티티 제공자(IdP)**가 사용자를 인증하고 서비스 제공자가 인가에 사용할 수 있는 토큰을 발급하게 합니다. SAML과 비슷하지만 Microsoft 기술에 크게 의존하는 시나리오에서 흔히 사용됩니다.
  • 예시: 사용자가 Microsoft Azure Active Directory(AD)에서 호스팅하는 기업 애플리케이션에 로그인하면, 그 신원을 서드파티 공급업체가 호스팅하는 애플리케이션을 포함한 다른 연합 서비스에 접근하는 데 사용할 수 있습니다.

WS-Federation은 많은 현대 웹 환경에서 OAuth2.0과 OpenID Connect 같은 더 새로운 프로토콜로 대체되었지만, 특히 Microsoft 중심 기업의 레거시 시스템에서는 여전히 사용됩니다.

5. LDAP (Lightweight Directory Access Protocol)

LDAP는 디렉터리 서비스에 접근하고 관리하는 데 사용되는 프로토콜로, 중앙 디렉터리(흔히 디렉터리 서비스라 부름)에서 사용자 자격 증명을 저장하고 접근 제어를 관리하는 데 흔히 쓰입니다. LDAP는 인증이나 인가 자체에 관한 것은 아니지만, 그러한 과정에서 사용되는 신원 데이터를 저장하고 조회하는 데 사용됩니다.

  • 인증: LDAP를 통해 애플리케이션은 디렉터리 서비스에서 자격 증명(비밀번호 등)을 조회하여 사용자를 인증할 수 있습니다.
  • 인가: 사용자 역할과 권한도 관리하여 사용자가 특정 리소스에 접근할 수 있는지 판단하는 데 도움을 줍니다.
  • 예시: 많은 기업이 특히 Windows 환경에서 인증과 인가를 위해 LDAP 기반 디렉터리(예: Active Directory)를 사용합니다.

LDAP는 기업이 내부 시스템 전반의 사용자 접근을 관리하는 데 매우 중요하지만, 현대 웹 맥락에서는 더 완전한 신원 관리를 위해 SAML이나 OAuth 같은 다른 프로토콜과 통합되는 경우가 많습니다.

6. 소셜 SSO 제공자

Facebook, Google, Twitter, GitHub 등 소셜 싱글 사인온(SSO) 제공자는 사용자가 소셜 미디어 자격 증명으로 서드파티 애플리케이션에 인증할 수 있게 해 줍니다. 이는 서드파티 서비스(예: Google)가 아이덴티티 제공자가 되는 일종의 OAuth 기반 인증입니다.

  • 흐름: 사용자가 (예를 들어) “Google로 로그인”을 클릭합니다. 앱은 Google로 리디렉션하고, 사용자는 (아직 로그인하지 않았다면) 그곳에서 로그인합니다. 그러면 Google은 서드파티 앱에 액세스 토큰이나 ID 토큰을 제공하며, 이는 사용자를 인증하고 경우에 따라 사용자의 데이터에 접근하는 데 쓰일 수 있습니다.
  • 예시: 많은 애플리케이션이 Google이나 Facebook 자격 증명으로 로그인하게 해 줍니다. 앱은 내부적으로 OAuth나 OpenID Connect를 사용하여 신원을 확인하고, 경우에 따라 일부 소셜 미디어 데이터에 접근합니다.

소셜 SSO는 사용자가 또 하나의 사용자 이름과 비밀번호를 만들기 원하지 않을 수 있으므로 마찰을 줄여 주기 때문에 편리하고 널리 채택된 인증 방법입니다.

차이점 요약:

  • OAuth: 인가에 사용되며, 서드파티 앱이 자격 증명을 노출하지 않고 사용자 데이터에 접근할 수 있게 합니다.
  • OpenID Connect: OAuth를 확장하여 인증을 제공하며, 앱이 사용자 신원을 확인할 수 있게 합니다.
  • SAML: SSO에 사용되는 XML 기반 프로토콜로, 주로 기업 환경에서 쓰입니다.
  • WS-Federation: 신원 연합을 위한 Microsoft 전용 프로토콜로, 레거시 시스템에서 쓰입니다.
  • LDAP: 사용자를 인증하고 인가를 관리하기 위해 디렉터리 서비스를 조회하는 프로토콜입니다.
  • 소셜 SSO 제공자: 서드파티 앱이 소셜 미디어 자격 증명으로 사용자를 인증할 수 있게 하는 OAuth 기반 시스템(Google, Facebook 등)입니다.

이러한 기술은 각각 고유한 강점과 사용 사례를 가지고 있으며, 현대 애플리케이션에서는 보안의 서로 다른 측면(예: API 접근에는 OAuth/OIDC, 기업 SSO에는 SAML)에 이들의 조합이 사용되는 것을 볼 수 있습니다.