OAuth 2.0과 OIDC 인증 흐름 완벽 가이드: 현대 웹 서비스 보안 핵심

OAuth 2.0과 OIDC의 개념, 동작 방식, 차이점, 그리고 실제 구현 가이드를 통해 안전하고 효율적인 인증 시스템 구축 방법을 알아봅니다.

점점 더 많은 서비스가 서로 연결되고, 우리는 다양한 플랫폼에서 수많은 애플리케이션을 사용합니다. 소셜 미디어 계정으로 쇼핑몰에 로그인하거나, 클라우드 서비스를 통해 다른 앱에 사진 접근 권한을 부여하는 등의 일은 우리에게 너무나도 익숙한 일상이 되었습니다. 하지만 이러한 편리함 뒤에는 '과연 내 개인 정보는 안전할까?', '어떻게 내 비밀번호를 직접 공유하지 않고도 다른 서비스에 권한을 줄 수 있을까?'와 같은 중요한 질문들이 숨어 있습니다.

이러한 질문에 대한 해답의 중심에는 바로 OAuth 2.0과 OpenID Connect (OIDC)라는 두 가지 핵심 프로토콜이 있습니다. 이들은 현대 웹과 모바일 서비스의 인증(Authentication) 및 인가(Authorization)를 담당하는 가장 중요한 기술 표준으로 자리 잡았습니다. 하지만 많은 개발자나 서비스 기획자들에게 이 두 프로토콜의 정확한 역할과 동작 방식, 그리고 서로의 관계는 여전히 혼란스럽게 다가올 수 있습니다.

이 글에서는 OAuth 2.0과 OIDC의 기본 개념부터 복잡한 동작 흐름, 그리고 각각의 장단점과 실제 적용 사례까지 완벽하게 파헤쳐보고자 합니다. 이 가이드를 통해 여러분은 안전하고 효율적인 인증/인가 시스템을 구축하는 데 필요한 지식을 얻게 될 것입니다.

📑 목차

• OAuth 2.0: 안전한 인가의 표준 프로토콜
• OAuth 2.0의 등장 배경 및 기본 개념
• OpenID Connect (OIDC): 인증 계층을 더하다
• OIDC의 필요성 및 주요 구성 요소
• OAuth 2.0과 OIDC의 핵심 동작 흐름 분석
• OAuth 2.0과 OIDC의 주요 Grant Type (또는 Flow)
• OAuth 2.0과 OIDC 비교: 언제 무엇을 사용할까?
• 언제 무엇을 사용할까?
• 결론: 안전하고 효율적인 인증 시스템 구축을 위한 선택

Image by Tumisu on Pixabay

OAuth 2.0: 안전한 인가의 표준 프로토콜

OAuth 2.0은 현대 웹 서비스에서 인가(Authorization)를 처리하는 데 사용되는 개방형 표준 프로토콜입니다. 여기서 인가란 '누가 무엇을 할 수 있는지'를 결정하는 과정을 의미합니다. 예를 들어, 특정 애플리케이션이 사용자의 동의하에 Google 드라이브 파일에 접근할 수 있도록 허용하는 것이 대표적인 인가 시나리오입니다.

OAuth 2.0의 등장 배경 및 기본 개념

기존에는 한 서비스가 다른 서비스의 리소스에 접근하려면 사용자가 자신의 계정 정보(아이디, 비밀번호)를 해당 서비스에 직접 제공해야 했습니다. 이는 다음과 같은 심각한 보안 문제를 야기했습니다.

• 비밀번호 유출 위험: 사용자가 계정 정보를 넘겨주는 순간, 해당 서비스가 악의적이라면 언제든 사용자의 계정을 탈취할 수 있습니다.
• 과도한 권한 부여: 모든 권한을 가진 계정 정보를 넘겨주므로, 특정 작업(예: 사진 업로드)만을 위한 최소한의 권한 부여가 불가능합니다.
• 권한 철회의 어려움: 비밀번호를 변경하지 않는 한, 한 번 부여된 권한을 특정 서비스에서만 철회하기 어렵습니다.

OAuth 2.0은 이러한 문제들을 해결하기 위해 리소스 소유자(Resource Owner)가 자신의 계정 정보를 직접 노출하지 않고도, 특정 클라이언트(Client) 애플리케이션에 제한된 범위의 접근 권한을 안전하게 위임할 수 있도록 설계되었습니다. 이 과정에서 액세스 토큰(Access Token)이라는 임시적인 자격 증명을 사용합니다.

OAuth 2.0의 핵심 구성 요소는 다음과 같습니다.

• 리소스 소유자 (Resource Owner): 보호된 리소스에 접근 권한을 가진 사용자입니다. (예: Google 사용자)
• 클라이언트 (Client): 리소스 소유자의 동의를 받아 보호된 리소스에 접근하고자 하는 애플리케이션입니다. (예: 사진 편집 앱)
• 인증 서버 (Authorization Server): 클라이언트에게 액세스 토큰을 발급하는 서버입니다. 리소스 소유자의 인가를 확인하고 토큰을 생성합니다. (예: Google 인증 서버)
• 리소스 서버 (Resource Server): 보호된 리소스를 호스팅하는 서버입니다. 클라이언트가 액세스 토큰을 제시하면 해당 토큰의 유효성을 검증하고 리소스 접근을 허용합니다. (예: Google Photos API 서버)

OAuth 2.0은 기본적으로 액세스 토큰을 발급하고 관리하는 프레임워크이며, 사용자 인증(Authentication)에는 직접적인 관여를 하지 않습니다. 오로지 '누가 어떤 리소스에 접근할 수 있는가'라는 인가 문제에 집중합니다.

OpenID Connect (OIDC): 인증 계층을 더하다

OAuth 2.0이 인가에 중점을 두었다면, OpenID Connect (OIDC)는 OAuth 2.0 위에 구축된 인증(Authentication) 계층입니다. 즉, OIDC는 OAuth 2.0의 인가 기능을 활용하여 '사용자가 누구인지'를 클라이언트 애플리케이션이 안전하게 확인할 수 있도록 해줍니다.

OIDC의 필요성 및 주요 구성 요소

OAuth 2.0만으로는 사용자가 성공적으로 로그인했는지, 그리고 그 사용자의 신원 정보(이름, 이메일 등)는 무엇인지 클라이언트가 알 수 없습니다. 클라이언트는 단지 액세스 토큰을 받아 리소스 서버에 접근할 수 있을 뿐입니다. 많은 애플리케이션은 단순히 리소스에 접근하는 것을 넘어, '누가 로그인했는지'를 알아야 합니다. 예를 들어, 사용자의 프로필 이미지를 보여주거나, 이메일 주소를 기반으로 맞춤형 서비스를 제공해야 합니다.

OIDC는 이러한 인증 요구사항을 해결하기 위해 등장했습니다. OIDC는 OAuth 2.0의 인가 코드 흐름(Authorization Code Flow)을 거의 그대로 사용하면서, 추가적으로 ID 토큰(ID Token)이라는 특별한 토큰을 도입했습니다.

• ID 토큰 (ID Token): 사용자의 신원 정보를 담고 있는 JWT(JSON Web Token) 형식의 토큰입니다. 이 토큰은 인증 서버가 직접 서명하므로, 클라이언트는 이 토큰을 통해 사용자가 누구인지, 언제 인증되었는지, 어떤 인증 서버를 통해 인증되었는지 등의 정보를 안전하게 확인할 수 있습니다.
• 사용자 정보 엔드포인트 (UserInfo Endpoint): ID 토큰에 모든 사용자 정보를 담기에는 너무 커질 수 있고, 민감한 정보는 ID 토큰에 직접 포함하지 않는 것이 좋습니다. UserInfo Endpoint는 클라이언트가 액세스 토큰을 사용하여 호출할 수 있는 API 엔드포인트로, 사용자의 추가적인 프로필 정보(이름, 이메일, 프로필 사진 URL 등)를 제공합니다.

결론적으로, OIDC는 OAuth 2.0의 유연한 인가 프레임워크 위에서 안전하고 표준화된 인증 방법을 제공함으로써 싱글 사인온(SSO, Single Sign-On)과 같은 시나리오를 가능하게 합니다.

OAuth 2.0과 OIDC의 핵심 동작 흐름 분석

가장 널리 사용되고 보안적으로 권장되는 흐름인 인가 코드 흐름 (Authorization Code Flow)을 중심으로 OAuth 2.0과 OIDC의 동작 방식을 상세히 살펴보겠습니다. OIDC는 이 흐름에 ID 토큰 발급 단계를 추가합니다.

1. 클라이언트, 인가 요청 (Authorization Request):
   • 사용자가 클라이언트 애플리케이션(예: 웹사이트)에서 'Google 로그인'과 같은 버튼을 클릭합니다.
   • 클라이언트는 사용자 브라우저를 인증 서버의 인가 엔드포인트(Authorization Endpoint)로 리다이렉트합니다. 이때, client_id, redirect_uri, scope(요청하는 권한 범위), state(CSRF 방지), 그리고 OIDC의 경우 response_type=code openid(openid 스코프는 OIDC 인증을 의미) 등의 파라미터를 함께 보냅니다.
   • PKCE(Proof Key for Code Exchange)를 사용하는 경우, code_challenge와 code_challenge_method도 포함됩니다.
2. 리소스 소유자, 인증 및 인가 (Authentication & Authorization):
   • 사용자는 인증 서버의 로그인 페이지로 이동하여 자신의 계정 정보로 로그인합니다.
   • 로그인 성공 후, 인증 서버는 클라이언트가 요청한 권한(scope) 목록을 사용자에게 보여주고 동의를 구합니다. (예: "이 앱이 귀하의 프로필 정보를 볼 수 있도록 허용하시겠습니까?")
   • 사용자가 동의하면, 인증 서버는 클라이언트에게 인가 코드(Authorization Code)를 발급합니다.
3. 인증 서버, 인가 코드 발급 (Authorization Code Grant):
   • 인증 서버는 미리 등록된 redirect_uri로 사용자의 브라우저를 다시 리다이렉트하면서, 쿼리 파라미터로 인가 코드와 state 값을 함께 전달합니다.
   • 클라이언트는 이 인가 코드를 받습니다. 이 코드는 매우 짧은 시간 동안만 유효하며, 한 번만 사용할 수 있습니다.
4. 클라이언트, 토큰 요청 (Token Request):
   • 클라이언트는 전달받은 인가 코드를 사용하여 인증 서버의 토큰 엔드포인트(Token Endpoint)에 직접(백엔드에서) 토큰을 요청합니다. 이때, client_id, client_secret(클라이언트 인증용), redirect_uri, grant_type=authorization_code, 그리고 받은 인가 코드를 함께 보냅니다.
   • PKCE를 사용하는 경우, code_verifier도 함께 보냅니다. 인증 서버는 code_verifier와 이전에 받은 code_challenge를 비교하여 요청의 유효성을 검증합니다.
5. 인증 서버, 토큰 발급 (Token Issuance):
   • 인증 서버는 클라이언트의 요청이 유효하면, 액세스 토큰(Access Token), 리프레시 토큰(Refresh Token)을 발급합니다.
   • OIDC의 경우, 추가적으로 사용자의 신원 정보를 담은 ID 토큰(ID Token)을 함께 발급합니다.
   • 이 토큰들은 클라이언트에게 JSON 형태로 응답됩니다.
6. 클라이언트, 리소스 접근 (Resource Access):
   • 클라이언트는 발급받은 액세스 토큰을 사용하여 리소스 서버에 보호된 리소스(예: 사용자 프로필, 드라이브 파일)를 요청합니다. 액세스 토큰은 보통 HTTP Authorization 헤더에 Bearer 타입으로 포함됩니다.
   • 리소스 서버는 액세스 토큰의 유효성을 검증하고, 토큰이 허용하는 범위 내에서 리소스에 대한 접근을 허용합니다.
7. OIDC 추가: 사용자 정보 조회 (UserInfo Endpoint Query):
   • OIDC를 사용하는 클라이언트는 ID 토큰을 파싱하여 사용자의 기본적인 신원 정보를 얻을 수 있습니다.
   • 더 많은 사용자 프로필 정보가 필요한 경우, 클라이언트는 액세스 토큰을 사용하여 인증 서버의 UserInfo Endpoint를 호출할 수 있습니다.

이러한 흐름은 사용자의 비밀번호가 클라이언트 애플리케이션에 직접 전달되지 않으며, 액세스 토큰은 특정 권한 범위와 유효 기간을 가지므로 보안성이 매우 높습니다.

Image by fsHH on Pixabay

OAuth 2.0과 OIDC의 주요 Grant Type (또는 Flow)

OAuth 2.0은 다양한 클라이언트 환경에 맞춰 여러 Grant Type(권한 부여 방식)을 제공합니다. 각 Grant Type은 토큰을 얻는 방식과 보안 특성이 다릅니다. OIDC는 주로 Authorization Code Flow를 기반으로 확장됩니다.

• Authorization Code Flow (인가 코드 흐름):
  • 설명: 가장 안전하고 널리 권장되는 방식입니다. 클라이언트가 인가 코드를 받은 후, 이 코드를 사용하여 인증 서버로부터 액세스 토큰을 직접(서버 대 서버 통신으로) 교환합니다. 클라이언트 시크릿(Client Secret)을 안전하게 보관할 수 있는 서버 측 웹 애플리케이션에 적합합니다.
  • OIDC와의 관계: OIDC의 기본 흐름으로 사용되며, ID 토큰 발급이 추가됩니다.
  • 보안 강화: PKCE(Proof Key for Code Exchange)를 함께 사용하면 모바일 앱이나 SPA(Single Page Application)와 같이 클라이언트 시크릿을 안전하게 보관하기 어려운 환경에서도 보안을 크게 강화할 수 있습니다. PKCE는 인가 코드 가로채기를 방지하는 데 효과적입니다.
• Implicit Flow (암시적 흐름):
  • 설명: 사용자 브라우저를 통해 액세스 토큰이 직접 전달되는 방식입니다. 인가 코드 교환 단계가 없어 간단하지만, 토큰이 URL 해시 프래그먼트를 통해 전달되므로 중간자 공격에 취약할 수 있습니다.
  • 현재 권장 여부: 보안 문제로 인해 더 이상 권장되지 않습니다. SPA에서는 Authorization Code Flow with PKCE를 사용하는 것이 좋습니다.
• Client Credentials Flow (클라이언트 자격 증명 흐름):
  • 설명: 사용자 개입 없이, 클라이언트 자신이 리소스 소유자가 되어 직접 액세스 토큰을 요청하는 방식입니다. 주로 서버 대 서버 통신이나 배치 작업 등에서 사용됩니다. client_id와 client_secret을 사용하여 인증 서버에 직접 토큰을 요청합니다.
  • 사용 예: 특정 서비스의 백엔드 시스템이 다른 서비스의 API에 접근할 때.
• Resource Owner Password Credentials Flow (리소스 소유자 비밀번호 자격 증명 흐름):
  • 설명: 클라이언트가 사용자의 아이디와 비밀번호를 직접 받아 인증 서버에 보내 액세스 토큰을 요청하는 방식입니다.
  • 현재 권장 여부: 사용자 비밀번호가 클라이언트에게 노출되므로 보안상 매우 취약하며, 특별한 경우를 제외하고는 절대 사용해서는 안 됩니다. 기존 레거시 시스템과의 호환성 등의 예외적인 상황에서만 고려될 수 있습니다.

각 Grant Type은 특정 사용 사례와 보안 요구 사항에 맞춰 설계되었습니다. 현대 애플리케이션 개발에서는 Authorization Code Flow with PKCE가 가장 보편적이고 안전한 선택입니다.

Image by andri333 on Pixabay

OAuth 2.0과 OIDC 비교: 언제 무엇을 사용할까?

이제 OAuth 2.0과 OIDC의 핵심적인 차이점과 공통점을 명확히 비교해보고, 어떤 상황에서 어떤 프로토콜을 선택해야 하는지 살펴보겠습니다.

항목	OAuth 2.0	OpenID Connect (OIDC)
주요 목적	인가(Authorization): 리소스 소유자의 동의하에 클라이언트에게 제한된 리소스 접근 권한을 위임	인증(Authentication): 사용자 신원을 확인하고 클라이언트에게 신원 정보 제공
기반 기술	독립적인 인가 프로토콜	OAuth 2.0 프레임워크 위에 구축된 인증 계층
핵심 토큰	액세스 토큰(Access Token): 리소스 서버 접근용	ID 토큰(ID Token): JWT 형식, 사용자 신원 정보 포함 + 액세스 토큰: 리소스 서버 접근용
제공 정보	클라이언트가 리소스 서버에 접근할 수 있는 권한	클라이언트가 사용자의 신원(누구인지)과 권한(무엇을 할 수 있는지) 모두 인지
주요 사용처	API 접근 제어, 타사 애플리케이션에 대한 리소스 접근 권한 위임	사용자 로그인, 싱글 사인온(SSO), 사용자 프로필 정보 획득
복잡성	비교적 간단 (인가에 집중)	OAuth 2.0보다 복잡 (인증 기능 추가)

언제 무엇을 사용할까?

• 단순히 API 접근 권한 위임이 목적이라면 OAuth 2.0:예를 들어, 여러분이 개발한 백엔드 서비스가 Google 캘린더 API에 접근하여 사용자 대신 이벤트를 생성해야 할 때, 사용자 로그인 정보는 필요 없고 단순히 캘린더 접근 권한만 필요하다면 OAuth 2.0만으로 충분합니다. 사용자가 누구인지는 중요하지 않고, '이 토큰이 캘린더에 접근할 권한이 있는가'만 중요합니다.
• 사용자 로그인, 신원 확인, SSO 구현이 목적이라면 OIDC:대부분의 웹 및 모바일 애플리케이션은 사용자가 누구인지 알아야 합니다. 로그인한 사용자의 이름을 보여주고, 개인화된 서비스를 제공하며, 여러 서비스 간에 한 번의 로그인으로 접근 가능한 SSO를 구현하려면 OIDC가 필수적입니다. OIDC는 ID 토큰을 통해 신뢰할 수 있는 사용자 신원 정보를 제공하므로, 클라이언트는 이 정보를 기반으로 사용자 경험을 구축할 수 있습니다.
• 현대 웹/모바일 애플리케이션 개발에서는 대부분 OIDC를 사용:실질적으로, 대부분의 서비스는 인증(사용자 누구인지)과 인가(무엇을 할 수 있는지)를 모두 필요로 합니다. 따라서 OIDC는 OAuth 2.0의 인가 기능을 포함하면서 인증 기능을 추가했기 때문에, 현대의 복잡한 애플리케이션 요구사항을 충족하는 데 더 적합합니다. 예를 들어, Google, Facebook, Naver, Kakao 등의 소셜 로그인은 모두 OIDC 기반으로 동작합니다.

결론: 안전하고 효율적인 인증 시스템 구축을 위한 선택

OAuth 2.0과 OpenID Connect (OIDC)는 현대 웹 서비스의 인증 및 인가 시스템을 구축하는 데 있어 가장 강력하고 유연한 도구입니다. OAuth 2.0이 인가의 표준 프레임워크로서 리소스 접근 권한 위임을 안전하게 처리한다면, OIDC는 그 위에 인증 계층을 추가하여 사용자 신원 확인과 싱글 사인온(SSO)을 가능하게 합니다.

두 프로토콜의 핵심적인 차이점을 이해하고, 여러분의 서비스가 인증을 필요로 하는지, 아니면 단순히 인가만을 필요로 하는지에 따라 적절한 프로토콜과 Grant Type을 선택하는 것이 중요합니다. 대부분의 경우, 사용자 로그인을 포함하는 애플리케이션은 Authorization Code Flow with PKCE를 활용한 OIDC를 사용하는 것이 가장 안전하고 효율적인 방법입니다.

안전한 시스템 구축을 위해서는 항상 최신 보안 권고 사항을 따르고, 액세스 토큰과 리프레시 토큰의 적절한 관리, PKCE와 같은 보안 강화 메커니즘의 적용, 그리고 모든 통신에 HTTPS 사용을 생활화해야 합니다.

이 글이 여러분의 인증 시스템 설계 및 구현에 명확한 가이드라인을 제공했기를 바랍니다. OAuth 2.0과 OIDC에 대해 궁금한 점이나 여러분의 경험을 공유하고 싶으시다면 언제든지 댓글로 남겨주세요!

📌 함께 읽으면 좋은 글

• [보안] DevSecOps 문화 도입, 보안 자동화 파이프라인 구축 전략 완벽 가이드
• [기술 리뷰] Tailwind CSS vs styled-components: 프론트엔드 스타일링, 실전에서 어떤 선택이 현명할까?
• [생산성 자동화] Jira와 Notion API 연동: 프로젝트 관리 워크플로우 자동화 완벽 가이드

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