인증 및 권한 프로토콜 개념 이해, 그리고 zero trust with keycloak

uchan·2024년 11월 11일

OAuth2.0 OpenID SAML keycloak zero trust

목표

Oauth2.0, OpenID, SAML, Zero trust 의 개념을 이해하자
zero trust 아키텍쳐를 keycloak 으로 구현할 수 있을까?

인증과 인가

인증(Authentication): 사용자가 누구인지 확인하는 절차로, 회원가입을 하고 로그인 하게 하는 것
인가(Authorization): 사용자에 사용 권한을 허락해 주는 절차로, 어떤 서비스에 로그인한 후에 이뤄지는 사용자의 행위에 대해 허가해 주는 것

Oauth2.0

OAuth 2.0은 인터넷 사용자가 제3자 웹사이트 또는 애플리케이션이 사용자 데이터를 특정 기간 동안 제한된 권한으로 액세스하도록 허용할 수 있게 하는 인증 및 권한 부여 프로토콜이다. OAuth 2.0은 보안이 강화된 방식으로 사용자 인증을 수행하며, 비밀번호를 공유하지 않고도 사용자 데이터에 접근할 수 있도록 설계되었습니다.

ref: https://www.geeksforgeeks.org/workflow-of-oauth-2-0/

리소스 소유자 : 나
리소스 서버 : 나의 데이터가 저장된 서버
클라이언트 : 내가 이용할 어플리케이션
권한 부여 서버: 인증 처리를 대신할 서버

예를 들어, 내가 프로그래머스 사이트에 회원가입할 때 나의 네이버 계정을 통해 생일, 프로필 이미지를 가져와 가입을 진행한다면 다음과 같다.

리소스 소유자 : 나
리소스 서버 : 네이버 계정 데이터가 담긴 서버
클라이언트 : 프로그래머스
권한 부여 서버: 네이버 로그인 서버

클라이언트는 리소스 소유자를 인증 서버로 연결하여 권한을 요청한다.
권한 부여 서버는 리소스 소유자를 인증하고 클라이언트와 리소스 사용자에게 알린다. 인증은 권한 부여 서버에서 수행되므로 클라이언트는 사용자 자격 증명에 액세스할 수 없다.
사용자가 보호된 데이터에 대한 액세스 권한을 부여하면, 권한 부여 서버는 임시 인증 코드를 사용하여 사용자를 클라이언트로 리디렉션한다.
클라이언트는 승인 코드와 교환하여 액세스 토큰을 요청한다.
권한 부여 서버는 클라이언트를 인증하고, 코드를 검증하고, 클라이언트에 액세스 토큰을 발급합니다.
클라이언트는 유효한 액세스 토큰을 리소스 서버에 제시하여 보호된 리소스에 액세스한다.

그렇다면 OAuth1.0 과 OAuth2.0 의 차이는 무엇일까? 그리고 왜 OAuth1.0 은 사라지게 된걸까?

토큰 사용 방식

OAuth 1.0은 요청에 서명이 필요하며, 액세스 토큰이 요청마다 포함된 서명을 통해 보호된다.
OAuth 2.0은 액세스 토큰만으로 보호되며, 클라이언트는 HTTPS를 통해 액세스 토큰을 사용해 리소스 서버에 요청한다. 이는 REST API와의 호환성을 높여주고, 인증 절차를 간소화할 수 있다.

리소스 소유자 자격 정보 보호

OAuth 1.0은 요청마다 클라이언트가 자격 정보를 직접 전달해야 했기 때문에, 보안이 위험하다.
OAuth 2.0은 자격 정보를 별도의 토큰으로 대체하여, 클라이언트가 자격 정보를 직접 다루지 않도록 했기에 사용자의 비밀번호가 클라이언트에 노출되는 것을 방지할 수 있다.

이외에도 보안 방식 개선(암호화 및 서명), 다양한 인증 흐름 지원, 간편한 구현 등을 통해 개발자의 부담을 덜어주는 이유도 있다.

OAuth2.0 은 사용자 인증보다는 권한을 부여하는데 초점이 맞춰져 있다. 즉, API를 연동하고 허가하기 위한 목적으로 인증보다는 인가에 가까운 프로토콜이다.

OpenID

OpenID는 비영리기관인 OpenID Foundation에서 추진하는 개방형 표준 및 분산 인증 프로토콜이다. 즉, OpenID는 인증을 위해 등장했다.

OpenID를 제공하는 웹사이트에서는 사용자는 웹사이트마다 모두 각자 계정을 만들고 관리할 필요가 없다. 대신 그들은 자신이 신뢰하는 OpenID 서비스 제공자(구글, 카카오 등)가 제공하는 OpenID 인증 서비스 하나만을 이용하여 인증하면 된다.

OpenID는 2006년 1.0버전을 표준으로 출시되었고, 이후 2007년에 2.0버전이 출시되었다. 그리고 2014년 3세대 OpenID로 OpenID Connect(OIDC)가 등장하게 되었다.

용어
OpenID는 대표적으로 2가지의 주체를 가리키는 용어가 존재한다. IdP와 RP이다.

IdP (Identity Provider)
IdP는 구글, 카카오와 같이 OpenID 서비스를 제공하는 당사자이다.

RP (Relying Party)
사용자를 인증하기 위해 IdP에 의존하는 주체이다. 'OOO으로 로그인하기' 따위의 기능을 제공하는 서비스 등을 의미한다.

OpenID Connect(OIDC)는 OpenID와 OAuth 2.0을 결합한 인증 프로토콜로, OAuth 2.0을 기반으로 하여 인증 기능을 추가한 표준이다. OIDC는 OAuth 2.0의 장점을 활용하면서 사용자 신원을 보다 안전하고 효율적으로 확인할 수 있다.

ref: https://hudi.blog/open-id/

SAML

앞서 OAuth2.0, OIDC 는 각 권한 및 인증을 JSON 기반으로 만든 표준이지만 SAML(Security Assertion Markup Language) 은 XML 기반의 인증 및 권한 부여 표준이다. SAML은 사용자가 여러 애플리케이션에 하나의 계정으로 접근할 수 있게 해준다. SAML은 사용자 인증을 외부의 신뢰할 수 있는 인증 제공자(Identity Provider, IdP)로부터 받아 다양한 애플리케이션에 인증 결과를 전달할 수 있도록 설계되었다.

SAML의 주요 구성 요소
1. Identity Provider (IdP): 사용자의 신원을 확인하고 인증 토큰을 발급하는 역할. 예를 들어, 회사의 IdP가 직원의 신원을 확인하고 SAML 응답을 발급한다.
2. Service Provider (SP): 애플리케이션이나 서비스로, IdP로부터 인증을 받고 접근 권한을 부여받는 곳이다. 예를 들어, 사내 포털이나 클라우드 서비스.
3. SAML Assertion: IdP가 SP에게 사용자의 인증 정보를 전달할 때 사용되는 XML 형식의 데이터. 이 어설션에는 인증, 사용자 속성, 권한 부여 등의 정보가 포함된다.

ref: https://knowledgehub.smartcommunications.com/v16/docs/saml

인증 요청: 사용자가 SAML 기반의 SSO가 적용된 애플리케이션(SP)에 접근하면, SP는 사용자 인증을 위해 IdP로 인증 요청을 보냅니다.
사용자 인증: IdP는 사용자의 자격 증명을 확인하여 사용자를 인증합니다.
SAML 어설션 발급: 인증이 성공하면, IdP는 SAML 어설션을 생성하고 사용자 정보를 SP로 보냅니다. 이 어설션에는 사용자 ID와 함께 SP가 요청한 특정 속성 정보가 담깁니다.
서비스 접근: SP는 IdP로부터 받은 어설션을 확인한 뒤, 사용자가 인증되었음을 인지하고 요청한 서비스에 접근할 수 있도록 합니다.

SAML vs OAuth vs OpenID Connect (OIDC)

특징	SAML	OAuth 2.0	OpenID Connect (OIDC)
주요 목적	인증 및 권한 부여 (주로 SSO)	권한 부여 (데이터 접근 권한 부여)	인증 및 권한 부여 (사용자 인증을 위한 OAuth 확장)
표준 형식	XML	JSON (주로 JWT)	JSON (JWT 기반)
사용 환경	주로 기업 환경 및 엔터프라이즈	애플리케이션 모바일 및 웹 애플리케이션의 권한 위임	OAuth 2.0 기반으로 다양한 웹 및 모바일 앱에서 사용 가능
주요 활용	SSO 및 연합 인증	제3자 애플리케이션에 대한 제한된 데이터 접근 권한 부여	사용자 인증을 위한 SSO 및 OAuth 확장

• SAML은 기업용 SSO 및 내부 애플리케이션 통합에서 주로 사용된다.
• OAuth 2.0은 애플리케이션 간의 데이터 접근 권한 부여를 위한 프로토콜로, 로그인보다는 권한 위임에 초점을 맞추고 있다.
• OpenID Connect는 OAuth 2.0을 확장하여 사용자 인증을 위한 프로토콜로 발전시킨 표준이다.

Zero trust

Zero Trust는 “절대 신뢰하지 않고 항상 검증한다”는 보안 접근 방식으로, 네트워크 내부와 외부를 구분하지 않고 모든 접근 요청을 검증하고 확인하는 것을 목표로 한다. 전통적인 네트워크 보안 모델은 내부는 신뢰하고 외부는 불신하는 방식을 따랐지만, Zero Trust는 내부와 외부를 불문하고 모든 접근 시도를 무조건 신뢰하지 않고 확인한다.

Zero Trust의 주요 원칙

모든 접근을 검증하라: 네트워크 내부의 요청이더라도 무조건 신뢰하지 않고, 사용자의 ID, 위치, 디바이스 상태, 작업 요청 등을 검증하여 신뢰성을 판단한다.
최소 권한 원칙(Least Privilege Access): 사용자와 애플리케이션에 필요한 최소한의 접근 권한만 부여합니다. 이를 통해 불필요한 권한을 제한하고, 내부적 위협이 발생하더라도 피해를 최소화한다.
다중 인증(Multi-Factor Authentication, MFA): 사용자 인증 시 ID와 비밀번호 외에도 추가적인 인증 수단(예: 지문, OTP, 보안키 등)을 요구하여 보안을 강화한다.
세분화된 네트워크: 네트워크를 여러 개의 세그먼트로 나누어, 각 세그먼트 사이의 트래픽을 제어하고 모니터링한다. 이를 통해 내부에서 발생하는 위협도 격리할 수 있다.
모니터링 및 로그 수집: 네트워크에서 발생하는 모든 활동을 모니터링하고 기록한다. 이를 통해 의심스러운 활동을 조기에 탐지하고 신속하게 대응할 수 있다.
동적 보안 정책 적용: 정책은 단순히 네트워크의 경계를 넘는 것뿐만 아니라, 사용자의 신원과 디바이스의 상태, 요청하는 애플리케이션에 따라 동적으로 설정되어야한다.

기존 방식 vs zero-trust

특징	전통적 보안 모델	Zero Trust 보안 모델
신뢰 범위	네트워크 내부 신뢰, 외부 불신	내부/외부 무관하게 모든 접근 요청을 검증
검증 방식	한 번 검증 후 대부분 신뢰	매번 사용자와 장치를 검증
네트워크 세분화	일반적으로 네트워크 전체를 신뢰	세분화하여 네트워크 내에서도 권한에 따른 접근 제어
사용자 접근 권한	필요 이상의 권한 부여 가능	최소 권한 접근 원칙 적용

Zero-trust with keycloak

keycloak 은 인증 및 권한 부여 오픈소스 플랫폼으로, 다양한 인증 방식과 세분화된 접근 제어 정책을 통해 사용자 인증과 자원 접근 관리를 강화하는 역할을 한다. keycloak 은 OAuth2.0, OIDC, SAML 모두 지원하며 애플리케이션에 사용자 인증 및 권한 부여 기능을 쉽게 추가할 수 있다. Keycloak은 널리 사용되는 프로그래밍 언어에 대한 다양한 클라이언트 라이브러리와 SDK를 제공하므로 웹 및 모바일 애플리케이션과 쉽게 통합할 수 있다.