클라이언트 타입
클라이언트 타입 (Client Type)
OAuth 2.0을 처음 설계할 때 가장 먼저 답해야 할 질문이 있어요. "우리 앱은 클라이언트 시크릿을 정말로 안전하게 지킬 수 있는 환경인가?" 이 답에 따라 클라이언트는 confidential과 public 두 가지 타입으로 나뉘어요. 이 구분이 중요한 이유는, 어떤 인증 방식과 어떤 플로를 쓸 수 있는지가 바로 이 타입에 달려 있기 때문이에요. 공식 스펙(RFC 6749 §2.1)에서 이 두 타입을 어떻게 정의하는지 먼저 보고 갈게요.
Confidential (비밀 보관형)
confidential 클라이언트는 인가 서버와 안전하게 인증할 수 있는 애플리케이션이에요. 대표적인 예가 등록한 클라이언트 시크릿(client secret)을 안전하게 보관할 수 있는 백엔드 서버(웹 서버 앱)예요. 이 타입은 시크릿을 이용해 인가 서버에 자신을 검증받을 수 있으므로, 시크릿이 필요한 여러 인증 방식을 쓸 수 있어요.
Public (비밀 보관 불가형)
public 클라이언트는 등록된 클라이언트 시크릿을 사용할 수 없는 애플리케이션이에요. 브라우저 안에서 동작하는 SPA나 모바일 앱처럼, 실행 환경 자체가 시크릿을 안전하게 숨길 수 없는 경우가 여기 해당해요. 이런 환경에서는 시크릿을 코드에 심어도 사용자가 디버깅 도구로 쉽게 꺼내 볼 수 있으니까, 시크릿 기반 인증을 믿을 수 없어요.
왜 이 구분이 실제로 중요할까요
타입에 따라 할 수 있는 게 달라져요. confidential 클라이언트는 시크릿을 쓰는 client authentication을 적용할 수 있고, public 클라이언트는 그럴 수 없어요. 그래서 public 클라이언트는 PKCE와 같은 별도 보안 확장에 의존해야 해요. 또 어떤 그랜트 타입을 쓸지 고를 때도 이 구분이 영향을 줘요. 예를 들어 클라이언트 크레덴셜(Client Credentials) 그랜트처럼 서버 대 서버 통신에 쓰이는 흐름은 confidential 클라이언트 전제로 설계된 경우가 많아요.
한눈에 정리 — 시크릿을 지킬 수 있으면 confidential, 그렇지 못하면 public. 브라우저·모바일 앱은 public, 백엔드 서버는 confidential이 대표 사례예요.