OAuth 2.1 OpenID Connect 기반 현대적 인증 인가 시스템 구축 가이드

OAuth 2.1과 OpenID Connect를 활용하여 안전하고 효율적인 인증/인가 시스템을 구축하는 방법을 친절하게 안내합니다. 최신 보안 표준을 통해 웹 서비스의 신뢰도를 높여보세요.

안녕하세요! 웹 서비스를 개발하다 보면 사용자 로그인과 데이터 보호는 항상 중요한 과제로 다가오죠. 예전처럼 아이디와 비밀번호를 직접 관리하는 방식은 보안 위험도 크고, 사용자 경험도 좋지 않아요. 여러 서비스에서 각각 로그인해야 하는 불편함도 있고요.

그래서 많은 서비스들이 구글, 카카오, 네이버 같은 소셜 로그인이나 SSO(Single Sign-On) 솔루션을 활용하는데요. 과연 이런 시스템들이 어떻게 안전하게 작동하는 걸까요? 그 중심에는 바로 OAuth 2.1과 OpenID Connect라는 강력한 두 가지 표준이 있답니다. 오늘은 이 두 가지를 활용해서 현대적이고 안전한 인증/인가 시스템을 구축하는 방법에 대해 자세히 알아볼 거예요!

📑 목차

• 왜 현대적 인증/인가 시스템이 필요할까요?
• OAuth 2.0, 그리고 왜 2.1로 진화했을까요?
• OAuth 2.0의 한계점과 2.1의 개선점
• OpenID Connect: 인증의 핵심, 신원 확인의 열쇠
• ID 토큰의 이해와 활용
• OAuth 2.1과 OpenID Connect, 어떻게 함께 작동할까요?
• 주요 인증 플로우 시나리오: 권한 코드 플로우 (Authorization Code Flow with PKCE)
• 실전! 현대적 인증/인가 시스템 구축 가이드
• 클라이언트 등록부터 토큰 발급까지
• 보안 고려사항과 구현 팁
• 마무리하며: 더 안전하고 편리한 웹의 미래

Image by Myriams-Fotos on Pixabay

왜 현대적 인증/인가 시스템이 필요할까요?

혹시 예전에 사용하던 웹사이트에서 내 개인 정보가 유출되었다는 소식을 들은 적 있으신가요? 아니면 서비스마다 다른 아이디와 비밀번호를 외우느라 고생했던 경험은요? 이런 문제점들이 바로 현대적 인증/인가 시스템이 필요한 이유를 설명해 줍니다.

과거에는 웹 서비스가 직접 사용자의 아이디와 비밀번호를 받아 데이터베이스에 저장하고 관리했어요. 이 방식은 개발이 단순하다는 장점은 있었지만, 몇 가지 치명적인 단점이 있었죠.

• 보안 취약성: 사용자 정보가 유출될 경우, 서비스 전체의 신뢰도가 떨어지는 것은 물론, 사용자는 심각한 피해를 입을 수 있어요.
• 사용자 경험 저하: 서비스마다 회원가입하고 로그인해야 하는 번거로움, 비밀번호를 잊어버렸을 때의 불편함은 사용자 이탈로 이어지기 쉽습니다.
• 확장성 부족: 여러 개의 서비스나 API를 운영할 때, 각 서비스마다 인증 시스템을 따로 구축하고 관리하는 것은 비효율적이에요.

현대적인 시스템은 이런 문제들을 해결하기 위해 '책임을 분리'하고 '권한을 위임'하는 방식으로 진화했습니다. 즉, 내가 직접 사용자의 신원을 확인하고 비밀번호를 관리하는 대신, 전문적인 신원 제공자(Identity Provider, IdP)에게 그 역할을 맡기는 거죠. 그리고 내 서비스는 IdP가 확인해준 신원 정보와 필요한 권한만 받아서 사용하게 되는 겁니다. 이게 바로 인증(Authentication)과 인가(Authorization)를 효과적으로 분리하고 연동하는 핵심이에요.

OAuth 2.0, 그리고 왜 2.1로 진화했을까요?

아마 OAuth라는 이름은 많이 들어보셨을 거예요. OAuth는 '권한 위임'을 위한 표준 프로토콜입니다. 쉽게 말해, 내가 어떤 서비스(예: 사진 편집 앱)가 내 구글 드라이브(리소스 서버)에 접근해서 사진을 가져올 수 있도록 '허락'해주는 방식인데요. 이때 내 구글 계정 아이디와 비밀번호를 사진 편집 앱에 직접 알려주지 않고도 권한을 부여할 수 있도록 해주는 것이 OAuth의 핵심입니다. 즉, OAuth는 '인가(Authorization)'를 위한 프레임워크인 거죠.

OAuth 2.0의 한계점과 2.1의 개선점

OAuth 2.0은 널리 사용되며 많은 서비스의 근간이 되었지만, 시간이 흐르면서 몇 가지 보안 취약점과 모호한 부분이 발견되기 시작했습니다. 대표적인 문제점으로는 다음과 같은 것들이 있었어요.

• 암묵적 플로우(Implicit Flow)의 위험성: 클라이언트(특히 SPA)에서 직접 토큰을 받는 방식인데, 토큰이 URL 해시 프래그먼트에 노출될 수 있어 탈취 위험이 높았습니다.
• PKCE(Proof Key for Code Exchange)의 선택적 적용: 모바일 앱이나 SPA 같은 퍼블릭 클라이언트에서 인가 코드 가로채기를 방지하는 중요한 메커니즘인데, 필수가 아니었어요.
• 리다이렉트 URI 불일치: 인가 서버에 등록된 `redirect_uri`와 요청 시 보내는 `redirect_uri`가 정확히 일치하지 않아도 허용되는 경우가 있어 피싱 공격에 악용될 수 있었습니다.

이러한 문제점들을 해결하고, 더 안전하고 간결한 표준을 만들기 위해 OAuth 2.1이 등장했습니다. OAuth 2.1은 기존 2.0의 장점은 유지하면서도, 보안을 강화하고 모범 사례들을 표준화한 버전이라고 할 수 있어요. 주요 개선점은 다음과 같습니다.

• 암묵적 플로우(Implicit Flow) 제거: 보안 취약성 때문에 더 이상 사용되지 않습니다. 대신 권한 코드 플로우(Authorization Code Flow)가 권장됩니다.
• PKCE 필수화: 퍼블릭 클라이언트(모바일 앱, SPA)에서 권한 코드 플로우를 사용할 때 PKCE 적용이 필수가 되었습니다. 이는 인가 코드가 탈취되더라도 공격자가 액세스 토큰을 얻지 못하도록 막아줍니다.
• 리다이렉트 URI의 엄격한 일치: 인가 서버에 등록된 `redirect_uri`와 요청 시 보내는 `redirect_uri`는 정확히 일치해야 합니다. 서브 도메인이나 포트까지도요.
• 리프레시 토큰(Refresh Token) 교환 시 `client_id` 필수: 클라이언트가 리프레시 토큰을 사용하여 새 액세스 토큰을 요청할 때 `client_id`를 포함하도록 하여 보안을 강화했습니다.

두 버전의 주요 차이점을 표로 정리해볼게요.

특징	OAuth 2.0	OAuth 2.1
권장 플로우	권한 코드, 암묵적, 클라이언트 자격 증명 등	권한 코드 플로우 (PKCE 필수)
암묵적 플로우 (Implicit Flow)	사용 가능 (SPA에서 주로 사용)	제거됨
PKCE (Proof Key for Code Exchange)	모바일/SPA에서 권장, 선택 사항	퍼블릭 클라이언트에서 필수
리다이렉트 URI 매칭	부분 일치 허용 가능	정확한 일치 필수
리프레시 토큰 교환	`client_id` 선택적	`client_id` 필수

결론적으로, OAuth 2.1은 OAuth 2.0의 보안 취약점을 개선하고 최신 보안 모범 사례를 강제하는 더욱 안전한 권한 위임 프레임워크라고 이해하시면 됩니다.

OpenID Connect: 인증의 핵심, 신원 확인의 열쇠

OAuth 2.1이 '권한 위임'을 위한 것이라면, OpenID Connect(OIDC)는 '인증'을 위한 표준입니다. 즉, "사용자가 누구인가?"를 확인하는 데 사용되죠. OIDC는 OAuth 2.1 위에 얇은 레이어처럼 추가되어, 사용자의 신원 정보를 안전하게 교환할 수 있도록 해줍니다.

OAuth 2.1만으로는 사용자가 인증되었는지, 그리고 그 사용자의 신원 정보(이름, 이메일 등)는 무엇인지 알 수 없어요. 단지 '이 사용자가 리소스에 접근할 수 있는 권한을 주었다'는 것만 알려줄 뿐이죠. 반면 OIDC는 OAuth 2.1의 인가 과정을 통해 ID 토큰(ID Token)이라는 특별한 토큰을 함께 발급하여 이 문제를 해결합니다.

ID 토큰의 이해와 활용

ID 토큰은 JWT(JSON Web Token) 형식으로 되어 있으며, 사용자의 신원 정보(Claim)를 포함하고 있습니다. 이 토큰은 인증 서버(IdP)가 발급하고, 클라이언트(내 서비스)는 이 토큰을 받아서 사용자의 신원을 검증하고 필요한 정보를 얻을 수 있습니다. ID 토큰에는 다음과 같은 정보들이 주로 담겨있어요.

• iss (Issuer): ID 토큰을 발급한 주체 (인증 서버 URL)
• sub (Subject): 사용자를 고유하게 식별하는 ID
• aud (Audience): 이 ID 토큰이 누구를 위해 발급되었는지 (클라이언트 ID)
• exp (Expiration Time): 토큰 만료 시간
• iat (Issued At): 토큰 발급 시간
• auth_time (Authentication Time): 사용자가 인증된 시간
• name: 사용자의 이름
• email: 사용자의 이메일 주소
• picture: 사용자 프로필 사진 URL

클라이언트는 ID 토큰을 받으면, 먼저 토큰의 서명을 확인하여 위변조 여부를 검증합니다. 그리고 iss, aud, exp 등의 클레임을 확인하여 유효성을 검증하죠. 이 모든 검증이 성공하면, 클라이언트는 해당 ID 토큰에 담긴 신원 정보를 믿고 사용자를 인증할 수 있게 됩니다.

간단한 ID 토큰 페이로드(디코딩된 내용) 예시를 볼까요?

{
  "iss": "https://accounts.google.com",
  "azp": "YOUR_CLIENT_ID.apps.googleusercontent.com",
  "aud": "YOUR_CLIENT_ID.apps.googleusercontent.com",
  "sub": "123456789012345678901",
  "email": "user@example.com",
  "email_verified": true,
  "at_hash": "a_valid_access_token_hash",
  "name": "홍길동",
  "picture": "https://lh3.googleusercontent.com/a/AATXAJx...s96-c",
  "given_name": "길동",
  "family_name": "홍",
  "locale": "ko",
  "iat": 1678886400,
  "exp": 1678890000
}

이처럼 ID 토큰 하나만으로 사용자의 신원을 안전하게 확인하고, 필요한 정보를 얻을 수 있기 때문에 OIDC는 현대 인증 시스템의 필수 요소로 자리 잡았습니다.

Image by Myriams-Fotos on Pixabay

OAuth 2.1과 OpenID Connect, 어떻게 함께 작동할까요?

이제 핵심입니다! OAuth 2.1은 인가, OpenID Connect는 인증이라는 것을 알았죠? 이 둘은 서로 다른 목적을 가지고 있지만, 실제 시스템에서는 마치 한 몸처럼 움직이며 상호 보완적인 역할을 수행합니다. OIDC가 OAuth 2.1 위에 '얹혀서' 작동한다고 생각하시면 이해하기 쉬울 거예요.

주요 인증 플로우 시나리오: 권한 코드 플로우 (Authorization Code Flow with PKCE)

가장 안전하고 널리 권장되는 플로우는 권한 코드 플로우 (Authorization Code Flow)이며, 특히 퍼블릭 클라이언트(SPA, 모바일 앱)에서는 PKCE(Proof Key for Code Exchange)를 함께 사용하는 것이 필수입니다. 이 과정을 단계별로 살펴볼게요.

1. 사용자 로그인 요청: 사용자가 내 서비스(클라이언트)에서 "구글로 로그인" 버튼을 클릭합니다.
2. 클라이언트, 인가 서버로 리다이렉트: 내 서비스는 사용자를 구글(인증/인가 서버)의 로그인 페이지로 리다이렉트합니다. 이때 client_id, redirect_uri, scope (어떤 정보/권한을 요청할지), state, 그리고 PKCE를 위한 code_challenge를 함께 보냅니다.
3. 사용자 인증 및 동의: 구글 로그인 페이지에서 사용자는 구글 계정으로 로그인하고, 내 서비스가 요청한 정보(예: 프로필, 이메일)와 권한에 동의합니다.
4. 인가 코드 발급: 구글은 사용자 인증 및 동의가 완료되면, 내 서비스에 등록된 redirect_uri로 사용자를 다시 리다이렉트하면서 인가 코드(Authorization Code)와 state 값을 함께 전달합니다.
5. 클라이언트, 토큰 요청: 내 서비스는 이 인가 코드를 받으면, 이 코드를 구글의 토큰 엔드포인트로 전송하여 액세스 토큰(Access Token), 리프레시 토큰(Refresh Token), 그리고 ID 토큰(ID Token)을 요청합니다. 이때 PKCE를 위한 code_verifier도 함께 보냅니다.
6. 토큰 발급: 구글은 code_challenge와 code_verifier가 일치하는지 확인하는 등 유효성 검증 후, 요청에 따라 토큰들을 발급하여 내 서비스로 전달합니다.
7. 클라이언트, 사용자 인증 및 리소스 접근: 내 서비스는 받은 ID 토큰을 검증하여 사용자의 신원을 확인하고 로그인 처리를 합니다. 이후 액세스 토큰을 사용하여 구글의 사용자 정보 API(리소스 서버)에 접근하여 추가적인 사용자 정보를 가져오거나, 다른 보호된 리소스에 접근할 수 있습니다. 리프레시 토큰은 액세스 토큰이 만료되었을 때 새 액세스 토큰을 얻는 데 사용됩니다.

이 과정에서 OIDC는 ID 토큰을 통해 '인증'을, OAuth 2.1은 액세스 토큰을 통해 '인가'를 담당하며 완벽한 인증/인가 시스템을 구축하는 거죠.

인가 요청의 예시를 보면 다음과 같습니다.

GET https://accounts.google.com/o/oauth2/v2/auth?
  response_type=code&
  client_id=YOUR_CLIENT_ID.apps.googleusercontent.com&
  scope=openid%20profile%20email&
  redirect_uri=https://YOUR_REDIRECT_URI.com/callback&
  state=YOUR_CSRF_TOKEN&
  code_challenge=YOUR_CODE_CHALLENGE&
  code_challenge_method=S256

위 요청에서 scope=openid%20profile%20email 부분이 OIDC를 사용하겠다는 의미이며, profile과 email 스코프를 통해 사용자의 이름과 이메일 정보를 요청하는 것입니다.

실전! 현대적 인증/인가 시스템 구축 가이드

이제 이론은 충분히 이해하셨으니, 실제 시스템을 구축할 때 어떤 점들을 고려해야 할지 실용적인 가이드를 드릴게요.

클라이언트 등록부터 토큰 발급까지

1. 인증/인가 제공자 (IdP) 선택:
   • 소셜 로그인 제공자: 구글, 카카오, 네이버, 페이스북 등은 이미 수많은 사용자를 확보하고 있어 편리한 로그인 경험을 제공합니다. 스타트업이나 소규모 서비스에 적합해요.
   • 전용 IdP 솔루션: Auth0, Okta, Keycloak 등은 더욱 세밀한 제어와 엔터프라이즈급 기능을 제공합니다. 복잡한 요구사항이나 대규모 서비스에 적합하죠.
   • 직접 구축: 매우 높은 수준의 커스터마이징이 필요하거나, 특정 보안 규제를 준수해야 할 때 고려할 수 있지만, 많은 시간과 전문성이 필요합니다.
2. 클라이언트 등록 및 설정:
   • 선택한 IdP 서비스 콘솔에서 내 서비스(클라이언트)를 등록해야 합니다. 이때 `client_id`와 `client_secret` (퍼블릭 클라이언트가 아니라면), 그리고 `redirect_uri`를 설정합니다.
   • redirect_uri는 매우 중요해요. 인가 코드를 받을 서버의 엔드포인트 주소를 정확히 입력해야 하며, 여러 개를 등록할 수도 있습니다.
3. SDK/라이브러리 활용:
   • 대부분의 IdP는 다양한 프로그래밍 언어와 프레임워크(React, Vue, Angular, Spring, Node.js 등)를 위한 SDK(Software Development Kit)나 라이브러리를 제공합니다. 이를 활용하면 직접 모든 플로우를 구현하는 수고를 덜 수 있고, 보안적으로 검증된 코드를 사용할 수 있어 안전합니다.
   • 예를 들어, React 환경이라면 react-oauth/google이나 oidc-client-ts 같은 라이브러리를 활용할 수 있습니다.
4. 토큰 검증 및 활용:
   • ID 토큰 검증: 클라이언트 측(프론트엔드 또는 백엔드)에서 ID 토큰을 받으면, 반드시 서명 검증과 클레임(iss, aud, exp 등) 검증을 수행해야 합니다. 이는 OIDC 라이브러리가 대부분 자동으로 처리해주지만, 동작 방식을 이해하는 것이 중요해요.
   • 액세스 토큰 활용: 보호된 리소스(API)에 요청을 보낼 때는 HTTP 헤더에 Authorization: Bearer [Access Token] 형태로 액세스 토큰을 포함하여 보냅니다. 리소스 서버는 이 토큰을 검증하여 요청의 유효성을 판단합니다.
   • 리프레시 토큰 관리: 리프레시 토큰은 액세스 토큰보다 수명이 길고 민감하므로, 매우 안전하게 저장하고 관리해야 합니다. 서버 측에서 DB에 저장하고 암호화하는 것이 일반적이며, 클라이언트(특히 브라우저)에 직접 저장하는 것은 권장하지 않습니다.

Image by Danielboos on Pixabay

보안 고려사항과 구현 팁

아무리 좋은 표준이라도 구현을 잘못하면 보안 취약점이 발생할 수 있어요. 다음은 현대적 인증/인가 시스템을 구축할 때 꼭 고려해야 할 보안 팁입니다.

• client_secret 안전하게 관리: 서버에서 사용하는 client_secret은 절대 클라이언트(브라우저, 모바일 앱)에 노출되어서는 안 됩니다. 환경 변수, Secrets Manager, KMS(Key Management Service) 등을 이용해 안전하게 보관하세요.
• redirect_uri 화이트리스트: IdP에 등록된 redirect_uri는 가능한 한 구체적으로 지정하고, 와일드카드 사용은 피하는 것이 좋습니다. 등록되지 않은 URI로의 리다이렉트를 막아 피싱 공격을 예방합니다.
• state 파라미터 활용: 인가 요청 시 state 파라미터에 CSRF(Cross-Site Request Forgery) 토큰을 생성하여 함께 보내고, 콜백 시 받은 state 값과 일치하는지 확인하세요. 이는 CSRF 공격을 방지하는 데 필수적입니다.
• PKCE 필수 적용: 싱글 페이지 애플리케이션(SPA)이나 모바일 앱 같은 퍼블릭 클라이언트에서는 PKCE를 반드시 적용해야 합니다. 인가 코드 탈취 공격으로부터 보호해줍니다.
• HTTPS 필수: 모든 통신은 반드시 HTTPS를 통해 이루어져야 합니다. HTTP 사용은 중간자 공격(Man-in-the-Middle)에 취약하며, 토큰 정보가 평문으로 노출될 수 있습니다.
• 토큰 탈취 방지:
  • XSS(Cross-Site Scripting) 방어: 클라이언트에 토큰을 저장할 경우, XSS 공격에 취약해질 수 있습니다. HttpOnly 속성이 있는 쿠키를 사용하거나, 로컬 스토리지 대신 메모리(변수)에 저장하는 것을 고려하세요.
  • CSRF 방어: state 파라미터 외에도 JWT를 사용할 경우 SameSite=Lax 또는 Strict 속성의 쿠키 사용을 고려할 수 있습니다.
• IDP의 보안 기능 활용: 대부분의 IdP는 MFA(Multi-Factor Authentication), 비정상 로그인 감지, 세션 관리 등 다양한 보안 기능을 제공합니다. 이를 적극적으로 활용하여 보안을 강화하세요.
• 로깅 및 모니터링: 인증/인가 관련 이벤트를 상세히 로깅하고, 비정상적인 접근 시도를 감지할 수 있도록 모니터링 시스템을 구축하는 것이 중요합니다.

마무리하며: 더 안전하고 편리한 웹의 미래

지금까지 OAuth 2.1과 OpenID Connect를 활용한 현대적 인증/인가 시스템 구축에 대해 자세히 알아보았어요. 이 두 가지 표준은 단순히 로그인 기능을 제공하는 것을 넘어, 사용자의 소중한 정보를 안전하게 보호하고, 여러 서비스 간의 유연한 연동을 가능하게 하는 핵심 기술이라고 할 수 있습니다.

물론 처음에는 복잡하게 느껴질 수도 있지만, 이 표준들을 제대로 이해하고 적용한다면 여러분의 서비스는 훨씬 더 안전하고, 사용자 친화적이며, 확장성 있는 시스템으로 거듭날 수 있을 거예요. 보안은 개발 과정에서 선택 사항이 아니라, 서비스의 성공을 위한 필수 요소라는 점을 잊지 마세요!

오늘 다룬 내용이 여러분의 프로젝트에 많은 도움이 되었으면 좋겠습니다. 혹시 궁금한 점이나 더 논의하고 싶은 부분이 있다면 언제든지 댓글로 남겨주세요. 함께 더 나은 웹을 만들어나가요!

📌 함께 읽으면 좋은 글

• [개발 도구] 터미널 생산성 극대화: Zsh, Oh My Zsh, Fish Shell 심층 비교 및 설정 가이드
• [커리어 취업] 개발자 이력서 합격률 높이는 전략: 직무 기술서 분석부터 차별화 경험 어필까지
• [보안] JWT 기반 인증 시스템, 실무 설계 및 구현 핵심 고려사항

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.