인증 및 인가 메커니즘 JWT 및 OAuth (r1)

인증은 사용자나 시스템의 신원을 확인하는 과정이다. 주로 '당신이 누구인가?'라는 질문에 답하는 역할을 한다. 이 과정은 사용자가 주장하는 신원이 진짜인지 검증하는 것을 목표로 한다. 일반적으로 아이디와 비밀번호를 입력받아 데이터베이스에 저장된 정보와 대조하는 방식이 가장 널리 알려져 있다.

인증의 수단은 다양하다. 지식 기반 인증(비밀번호, PIN), 소유물 기반 인증(스마트카드, 보안 토큰), 생체 기반 인증(지문, 얼굴 인식) 등이 대표적이다. 최근에는 이러한 요소 중 두 가지 이상을 결합하는 다중 요소 인증(MFA)이 보안 강화를 위해 점차 표준으로 자리 잡고 있다.

인증이 성공하면, 시스템은 일반적으로 해당 사용자의 세션을 생성하거나 인증 토큰을 발급한다. 이 토큰은 이후 사용자의 요청이 이미 신원이 확인된 사용자로부터 온 것임을 증명하는 데 사용된다. 인증은 모든 보안 프로세스의 첫 번째 관문으로, 이후 이루어지는 인가 결정의 기초를 제공한다.

인가는 인증을 통해 확인된 사용자나 시스템이 특정 자원이나 기능에 접근할 수 있는 권한이 있는지를 판단하는 과정이다. 즉, '무엇을 할 수 있는가'를 결정하는 절차이다. 인가 과정에서는 사용자의 신원, 역할(역할 기반 접근 제어), 소속 그룹, 또는 개별적으로 부여된 권한 목록과 같은 정보를 바탕으로 접근 요청을 허용하거나 거부한다.

인가 정책은 일반적으로 애플리케이션의 비즈니스 로직에 내재되어 있으며, 다양한 모델로 구현된다. 대표적인 모델로는 특정 작업 실행 권한을 부여하는 권한(Permission) 기반 모델, 사전에 정의된 역할(Role)에 권한을 할당하는 역할 기반 접근 제어(RBAC), 그리고 객체와 주체 간의 복잡한 관계를 규칙으로 표현하는 속성 기반 접근 제어(ABAC) 등이 있다.

예를 들어, 문서 관리 시스템에서 사용자가 'A문서.pdf' 파일을 삭제하려고 할 때, 시스템은 먼저 해당 사용자가 로그인한 유효한 사용자인지 확인한다(인증). 그 후, 이 사용자가 'A문서.pdf'에 대한 삭제 권한을 가지고 있는지, 또는 '관리자' 역할을 보유하고 있는지 등을 검증한다(인가). 이 검증을 통해 권한이 부여된 경우에만 삭제 작업이 수행된다.

이러한 인가 메커니즘은 API 엔드포인트 접근 제어, 파일 시스템 권한 설정, 데이터베이스 레코드에 대한 CRUD 작업 제한 등 소프트웨어 시스템의 보안과 데이터 무결성을 유지하는 데 필수적이다.

인증과 인가는 정보 보안의 핵심 개념으로, 서로 밀접하게 연관되어 있지만 명확히 구분되는 목적을 가진다. 인증은 사용자나 시스템의 신원을 확인하는 과정이며, 인가는 해당 신원이 특정 자원이나 기능에 접근할 권한이 있는지를 결정하는 과정이다.

두 개념의 관계는 순차적이고 계층적이다. 일반적으로 인증이 먼저 수행되어 신원이 검증된 후, 그 신원을 바탕으로 인가가 이루어진다. 예를 들어, 사용자가 로그인(인증)을 성공하면 시스템은 해당 사용자의 역할(Role)이나 권한(Permission)을 확인하여 특정 파일을 열거나 관리자 페이지에 접근할 수 있는지(인가)를 판단한다. 인증 없이는 의미 있는 인가 결정을 내릴 수 없다.

차이점은 다음과 같이 요약할 수 있다.

따라서 인증은 접근의 출입문을 여는 열쇠 역할을 하고, 인가는 건물 내부에서 각 방에 들어갈 수 있는 권한을 규정하는 내부 규칙에 비유할 수 있다. 효과적인 보안 체계를 구축하기 위해서는 이 두 메커니즘을 명확히 구분하고, 각각에 적합한 기술(예: JWT를 통한 인증, OAuth 스코프(Scope)를 통한 인가)을 적용하는 것이 중요하다.

JWT는 점('.')으로 구분된 세 부분, 즉 헤더(Header), 페이로드(Payload), 서명(Signature)으로 구성된다. 이 세 부분은 각각 Base64Url 인코딩되어 있으며, 이를 결합하여 최종적인 JWT 문자열을 형성한다[1].

헤더는 일반적으로 토큰의 유형(typ)과 사용된 서명 알고리즘(alg) 두 가지 정보를 담는다. 가장 일반적인 형태는 {"alg": "HS256", "typ": "JWT"}와 같다. 페이로드는 토큰에 담을 정보인 클레임(Claim)들을 포함한다. 클레임은 등록된 클레임(Registered claims), 공개 클레임(Public claims), 비공개 클레임(Private claims)으로 분류된다. 등록된 클레임은 미리 정의된 의미를 가진 권장 클레임으로, 발급자(iss), 주제(sub), 수신자(aud), 만료 시간(exp), 발행 시간(iat) 등이 있다.

서명 부분은 인코딩된 헤더, 점, 인코딩된 페이로드를 합친 문자열을, 헤더에 지정된 알고리즘과 비밀 키(Secret Key) 또는 공개/개인 키 쌍을 사용하여 생성한다. 이 서명은 토큰이 전송 중에 변조되지 않았음을 검증하는 데 사용된다. 세 부분의 구조는 다음 표와 같이 요약할 수 있다.

최종적인 JWT는 헤더.페이로드.서명의 형태를 띤다. 예를 들어, 생성된 JWT는 xxxxx.yyyyy.zzzzz와 같은 모습이다. 클라이언트는 이 토큰을 보관하고, 보호된 리소스에 접근할 때 HTTP 요청의 Authorization 헤더에 담아 서버로 전송한다. 수신한 서버는 서명을 검증하여 토큰의 유효성과 무결성을 확인한 후, 페이로드에 담긴 클레임 정보를 신뢰하고 사용한다.

JWT는 일반적으로 클라이언트가 서버에 인증 정보(예: 사용자명과 비밀번호)를 제출한 후, 서버가 그 유효성을 검증하고 발급하는 액세스 토큰으로 사용된다. 기본적인 작동 흐름은 다음과 같다. 먼저, 사용자가 클라이언트 애플리케이션을 통해 로그인 자격 증명을 제출한다. 그런 다음, 인증 서버는 해당 자격 증명을 검증하고, 검증이 성공하면 서명된 JWT를 생성하여 클라이언트에게 응답으로 반환한다. 클라이언트는 이 JWT를 로컬에 저장한 후(주로 로컬 스토리지나 쿠키), 이후 보호된 리소스 서버(API 서버)에 요청을 보낼 때마다 HTTP 요청의 Authorization 헤더에 이 토큰을 담아 전송한다. 리소스 서버는 토큰의 서명을 검증하고, 페이로드에 포함된 정보를 신뢰하여 요청을 처리한다.

JWT의 핵심 작동 원리는 디지털 서명에 기반한 자기 수용적(self-contained) 정보 전달에 있다. 토큰 자체에 서명이 포함되어 있기 때문에, 리소스 서버는 토큰 발급자(인증 서버)에 별도로 문의하지 않고도 토큰의 진위와 무결성을 검증할 수 있다. 이는 상태 비저장(Stateless) 아키텍처를 가능하게 하는 중요한 특징이다. 서버는 사용자 세션 상태를 메모리나 데이터베이스에 유지할 필요 없이, 들어오는 각 JWT의 서명만 검증하면 된다.

다음은 JWT 기반 인증의 일반적인 시퀀스를 나타낸다.

이 흐름에서 주의할 점은, JWT가 발급된 후에는 서버 측에서 강제로 폐기하기 어렵다는 것이다. 토큰의 유효 기간이 만료될 때까지는 유효한 것으로 간주되므로, 토큰 탈취 시 발생할 수 있는 보안 위험을 완화하기 위해 비교적 짧은 유효 기간을 설정하는 것이 일반적인 모범 사례이다. 또한, 민감한 정보는 토큰 페이로드에 포함하지 않아야 하며, 서명 검증을 반드시 수행해야 한다.

JWT는 무상태성을 기반으로 하여 서버 측에서 세션 정보를 저장할 필요가 없다. 이는 서버의 부하를 줄이고 확장성을 높이는 데 기여한다. 또한 JSON 형식의 토큰은 다양한 프로그래밍 언어와 플랫폼에서 쉽게 파싱하고 처리할 수 있어 범용성이 뛰어나다. 토큰 자체에 필요한 정보(클레임)를 포함할 수 있어, 데이터베이스 조회 없이도 사용자 정보를 확인하는 데 사용될 수 있다.

하지만 JWT는 한번 발급되면 만료 시간이 도래하기 전에는 폐기하기 어렵다는 단점을 가진다. 이는 토큰이 탈취당했을 때 발생하는 보안 문제로 이어진다. 세션 방식은 서버 측에서 세션을 무효화할 수 있지만, JWT는 일반적으로 블랙리스트를 관리하는 추가 메커니즘 없이는 중간에 취소할 수 없다.

또한 토큰의 페이로드는 암호화되지 않고 단지 Base64Url로 인코딩되어 있기 때문에, 민감한 정보를 저장하는 데는 적합하지 않다. 누구나 디코딩하여 내용을 볼 수 있기 때문이다. 토큰의 크기가 세션 ID에 비해 상대적으로 커질 수 있어, 매 요청마다 전송되는 오버헤드가 발생할 수 있다.

OAuth 2.0은 제3의 애플리케이션이 사용자의 자원에 제한적으로 접근할 수 있도록 허용하는 인가 프레임워크이다. 그 핵심 역할은 사용자가 자신의 비밀번호를 제3자에게 노출시키지 않으면서도, 특정 자원에 대한 접근 권한을 안전하게 위임할 수 있게 하는 것이다. 예를 들어, 소셜 미디어 앱이 사용자의 구글 캘린더에 일정을 추가하거나, 뉴스 애플리케이션이 사용자의 트위터 계정에 글을 자동으로 올릴 수 있도록 허용하는 과정에서 OAuth 2.0이 사용된다.

OAuth 2.0의 등장 배경은 OAuth 1.0의 복잡성과 실용적인 문제를 해결하기 위해서이다. 2006년에 시작된 OAuth 1.0 프로토콜은 디지털 서명을 기반으로 한 강력한 보안 모델을 제공했지만, 구현이 복잡하고 클라이언트 측 개발자에게 부담이 컸다. 특히 모바일 애플리케이션이나 데스크톱 애플리케이션과 같은 네이티브 앱에서의 적용이 어려웠다. 또한, 암호화가 아닌 서명을 사용했기 때문에 HTTPS 사용이 필수가 아니라는 점도 보안상 논란의 여지가 있었다.

이러한 문제점을 극복하기 위해 2012년에 공식 표준으로 채택된 OAuth 2.0은 설계 철학을 크게 바꾸었다. 핵심 변화는 다음과 같다.

결과적으로 OAuth 2.0은 더 간단하고 유연한 프레임워크가 되어, 다양한 현대 애플리케이션 환경(모바일, 싱글 페이지 애플리케이션, IoT 디바이스 등)에서 폭넓게 채택되는 산업계의 사실상(de facto) 표준이 되었다.

OAuth 2.0 프레임워크는 네 가지 핵심 역할로 정의된 구성 요소 간의 상호작용을 통해 동작한다. 이 구성 요소들은 각각 명확한 책임을 가지며, 안전한 위임된 인가를 가능하게 한다.

주요 구성 요소는 다음과 같다.

Resource Owner는 Client가 자신의 자원에 접근하도록 허용한다. Client는 Authorization Server를 통해 Resource Owner로부터 인가를 받고, 그 증표인 액세스 토큰을 획득한다. 이후 Client는 이 토큰을 Resource Server에 제시하여 실제 자원(예: 사용자 데이터)에 접근한다. Authorization Server와 Resource Server는 동일한 서비스 제공자 내에 존재할 수도 있고, 분리되어 있을 수도 있다. 이 분리된 아키텍처는 마이크로서비스 환경에서 특히 중요하게 작동한다.

OAuth 2.0은 다양한 애플리케이션 시나리오를 지원하기 위해 여러 권한 부여 방식을 정의한다. 각 방식은 클라이언트의 유형과 신뢰 수준, 리소스 오너의 참여 방식에 따라 적합한 상황이 다르다.

가장 일반적으로 사용되는 방식은 다음과 같다.

권한 부여 코드 방식은 보안성이 가장 뛰어나 표준적인 웹 애플리케이션에서 널리 채택된다. 이 방식에서는 민감한 액세스 토큰이 사용자의 브라우저를 직접 거치지 않고 서버 간에 교환된다. 암시적 방식은 단순하지만 토큰이 브라우저 히스토리나 로그에 노출될 위험이 있어, OpenID Connect와 같은 현대 프로토콜에서는 사용을 지양한다.

클라이언트 자격 증명 방식은 사용자 컨텍스트가 없는 서비스 계정이나 백그라운드 프로세스에 적합하다. 리소스 오너 패스워드 자격 증명 방식은 사용자의 자격 증명을 클라이언트가 처리해야 하므로, 해당 클라이언트를 완전히 신뢰할 수 있는 매우 제한된 경우에만 사용해야 한다. 또한, 인증 서버는 보안을 강화하기 위해 발급된 토큰에 JWT를 활용할 수 있다.

OAuth 2.0 프레임워크는 액세스 토큰의 구체적인 형식을 규정하지 않는다. 이는 구현체의 자유도를 보장하는 설계 선택이다. JWT는 이러한 액세스 토큰으로 널리 채택된 형식 중 하나이다. 인증 서버는 권한 부여를 완료한 후, 클라이언트에게 JWT 형식의 액세스 토큰을 발급할 수 있다.

JWT가 액세스 토큰으로 사용될 때의 주요 이점은 자체 포함성(self-contained)이다. 토큰의 페이로드 섹션에 클라이언트 식별자, 사용자 권한(스코프), 만료 시간 등의 필요한 정보를 직접 인코딩할 수 있다. 이는 리소스 서버가 매 요청마다 인증 서버에 토큰을 검증하러 갈 필요 없이, 서명을 검증하고 페이로드를 디코딩함으로써 토큰의 유효성과 권한을 즉시 판단할 수 있게 한다. 이 방식은 상태를 저장하지 않는(Stateless) 서버 아키텍처와 잘 맞으며, 인증 서버에 대한 의존성과 조회 부하를 줄여 확장성을 높인다.

그러나 이 접근 방식에는 주의사항이 따른다. JWT는 일단 발급되면 만료 시간이 도래하기 전에는 중간에 폐기(revoke)하기 어렵다는 특징을 가진다. 이는 보안 상의 취약점으로 작용할 수 있다. 이를 완화하기 위해 짧은 만료 시간을 사용하고, 리프레시 토큰을 함께 발급하여 주기적으로 새로운 액세스 토큰으로 교체하는 전략이 일반적이다. 또한, 민감한 사용자 정보를 페이로드에 포함시키면 토큰이 탈취되었을 때 정보가 노출될 위험이 있으므로, 필요한 최소한의 정보만 포함시키는 것이 모범 사례이다.

결론적으로, OAuth 2.0에서 JWT는 액세스 토큰의 효율적인 구현체로 동작한다. 이 조합은 분산 시스템에서 표준화된 방식으로 권한을 전달하고 검증하는 강력한 메커니즘을 제공하지만, 토큰의 수명 관리와 정보 노출에 대한 신중한 설계가 필요하다.

OAuth 2.0은 권한 부여 프레임워크를 제공하고, JWT는 그 권한을 증명하는 토큰의 구체적인 형식 중 하나로 사용된다. 두 기술을 함께 사용하는 가장 일반적인 패턴은 OAuth 2.0의 액세스 토큰을 JWT 형식으로 발급하는 것이다. 이 경우 인가 서버는 사용자의 인증 및 권한 부여를 완료한 후, 사용자 정보와 권한 범위(스코프)를 페이로드에 담고 서명된 JWT를 생성하여 클라이언트에게 전달한다. 클라이언트는 이 JWT를 액세스 토큰으로 사용하여 리소스 서버에 API 요청을 보낸다.

리소스 서버는 전달받은 JWT의 서명을 공개 키로 검증하여 토큰의 진위와 무결성을 확인한다. 서명 검증이 성공하면, 리소스 서버는 별도의 데이터베이스 조회 없이도 JWT 페이로드에 포함된 정보(예: 사용자 식별자, 권한, 토큰 만료 시간)를 직접 파싱하여 요청을 처리할 수 있다. 이는 상태 비저장 아키텍처를 구현하는 데 핵심적인 역할을 하며, 서버의 확장성을 높여준다.

보다 정교한 패턴으로는 JWT를 리프레시 토큰과 함께 사용하는 방식이 있다. 짧은 수명의 JWT를 액세스 토큰으로, 긴 수명의 불투명한 토큰을 리프레시 토큰으로 발급한다. 액세스 토큰이 만료되면 클라이언트는 리프레시 토큰을 사용해 인가 서버에 새로운 액세스 토큰을 요청한다. 이 패턴은 보안성을 강화하면서도 사용자 경험을 유지한다.

또한, 마이크로서비스 아키텍처 환경에서는 JWT가 서비스 간의 신원 전파 수단으로 널리 활용된다. 초기 인증을 마친 사용자에 대한 JWT가 생성되면, 이 토큰은 여러 하위 서비스로 전달된다. 각 서비스는 중앙 인가 서버에 문의하지 않고도 JWT를 검증하여 사용자 컨텍스트를 이해하고 권한을 확인할 수 있다. 이는 API 게이트웨이가 토큰을 검증하고 하위 서비스로 전달하는 구조와 잘 결합된다.

JWT는 그 구조와 사용 방식으로 인해 몇 가지 고유한 보안 취약점을 가질 수 있다. 가장 큰 위험은 토큰 자체가 탈취되는 경우이다. JWT는 기본적으로 상태를 저장하지 않기([3]), 한 번 발급되면 만료 시간이 도래하기 전까지는 무효화하기 어렵다. 따라서 토큰이 유출되면 공격자는 유효 기간 내에 해당 토큰의 권한을 그대로 행사할 수 있다. 이를 완화하기 위해 토큰의 만료 시간(exp 클레임)을 짧게 설정하고, Refresh Token을 사용하여 주기적으로 새로운 액세스 토큰을 발급받는 방식을 적용한다. 또한 중요한 작업에 대해서는 추가적인 인증(예: 비밀번호 재입력)을 요구하는 것이 좋다.

서명 검증의 누락은 치명적인 보안 허점이다. JWT의 무결성과 신뢰성은 전적으로 서명(Signature)에 의존한다. 서버는 수신한 토큰의 서명을 반드시 발급자(iss 클레임)의 비밀 키(HMAC) 또는 공개 키(RSA/ECDSA)를 사용하여 검증해야 한다. 특히 알고리즘 헤더를 조작하는 공격(Algorithm Confusion Attack)을 방지하기 위해, 서버는 허용할 서명 알고리즘을 명시적으로 지정하고 클라이언트가 제시하는 알고리즘을 그대로 수용해서는 안 된다. "none" 알고리즘 사용은 절대 허용하지 않아야 한다.

토큰에 저장되는 정보의 민감성도 고려해야 한다. 페이로드는 서명으로 보호되지만, 기본적으로 암호화되지 않기 때문에 누구나 Base64Url 디코딩을 통해 내용을 읽을 수 있다. 따라서 JWT 내부에는 비밀번호나 개인 식별 정보(PII)와 같은 민감 데이터를 포함시키지 말아야 한다. 필요한 경우 JWE(JSON Web Encryption)를 사용하여 토큰 전체를 암호화할 수 있다. 또한 클레임을 과도하게 많이 포함시키면 토큰 크기가 커져 네트워크 오버헤드를 증가시킬 수 있다.

OAuth 2.0 구현 시 보안을 유지하기 위해서는 프레임워크의 설계 원칙을 정확히 이해하고 여러 공격 벡터에 대비해야 한다. 가장 중요한 원칙 중 하나는 클라이언트 시크릿의 안전한 관리이다. 서버 사이드 애플리케이션의 경우 시크릿은 절대 클라이언트 측에 노출되어서는 안 되며, 안전한 백엔드 저장소에 보관해야 한다. 모바일 앱이나 싱글 페이지 애플리케이션과 같은 퍼블릭 클라이언트는 시크릿을 안전하게 저장할 수 없으므로, 인가 코드 흐름과 PKCE를 반드시 조합하여 사용해야 한다. PKCE는 인가 코드를 탈취당했을 때도 액세스 토큰 교환을 방지하는 추가 보안 계층을 제공한다.

리디렉션 URI의 검증은 또 다른 핵심 보안 조치이다. 인가 서버는 사전에 등록된 정확한 리디렉션 URI로만 응답을 전송해야 하며, 등록되지 않거나 변조된 URI에 대한 요청은 거부해야 한다. 이를 통해 공격자가 토큰을 자신이 통제하는 엔드포인트로 유도하는 공격을 차단할 수 있다. 또한, 발급된 액세스 토큰은 가능한 짧은 수명을 가지도록 설정하고, 리프레시 토큰은 더 엄격하게 보호해야 한다. 리프레시 토큰은 반드시 안전한 저장소에 보관하고, 토큰 순환 정책을 적용하여 재사용을 탐지하고 차단하는 메커니즘을 마련하는 것이 좋다.

마지막으로, 인가 서버와 리소스 서버 간의 통신, 그리고 모든 토큰 전송은 반드시 TLS를 통해서만 이루어져야 한다. 또한, 클라이언트가 특정 범위만 요청할 수 있도록 권한 범위를 최소화하는 원칙을 적용하고, 의심스러운 토큰 사용 패턴을 모니터링하는 로깅 및 감사 체계를 구축하는 것이 장기적인 보안에 필수적이다.

다양한 프로그래밍 언어와 프레임워크는 JWT 생성/검증 및 OAuth 2.0 클라이언트/서버 구현을 지원하는 공식 및 서드파티 라이브러리를 제공한다. 이러한 라이브러리는 암호화 서명, 표준 준수 흐름 처리와 같은 복잡한 저수준 작업을 추상화하여 개발자가 보안 인증 로직에 집중할 수 있게 돕는다.

주요 언어별 대표적인 라이브러리는 다음과 같다.

라이브러리 선택 시 지원하는 JWA 알고리즘 범위, OAuth 2.0 권한 부여 유형의 구현 완성도, 문서화 상태, 커뮤니티 활성도 및 최근 업데이트 빈도를 고려하는 것이 좋다. 특히 OAuth 2.0 서버 측 구현의 경우 OpenID Connect 확장을 함께 지원하는 라이브러리가 현대적 애플리케이션에 더 적합하다. 대부분의 라이브러리는 공식 RFC 7519 및 RFC 6749 표준을 준수하며, 보안 취약점 패치에 대한 신속한 대응 여부도 중요한 평가 기준이 된다.

구현 예시는 클라이언트 사이드가 리소스 서버의 보호된 데이터에 접근하는 일반적인 시나리오를 가정한다. 여기서는 권한 부여 코드 승인 방식(Authorization Code Grant)과 JWT를 액세스 토큰으로 사용하는 흐름을 설명한다.

클라이언트 애플리케이션은 먼저 사용자를 인증 서버의 로그인 페이지로 리다이렉트한다. 사용자가 성공적으로 로그인하고 접근 권한을 승인하면, 인증 서버는 미리 등록된 리다이렉트 URI로 권한 부여 코드를 발급한다. 클라이언트는 이 코드와 자신의 클라이언트 비밀키를 사용하여 인증 서버의 토큰 엔드포인트에 요청을 보내고, 응답으로 JWT 형식의 액세스 토큰과 리프레시 토큰을 받는다.

클라이언트는 획득한 JWT를 이후 모든 보호된 API 요청의 Authorization: Bearer <토큰> 헤더에 포함시킨다. 리소스 서버는 별도로 인증 서버에 문의하지 않고도 JWT의 디지털 서명을 검증하여 토큰의 유효성과 발행자를 확인할 수 있다. 토큰이 만료되면 클라이언트는 저장해둔 리프레시 토큰을 사용하여 새로운 액세스 토큰을 자동으로 발급받을 수 있다. 이 흐름은 싱글 페이지 애플리케이션, 모바일 앱, 서버 측 웹 애플리케이션 등에 적용 가능한 기본 패턴이다.

OpenID Connect(OIDC)는 OAuth 2.0 프레임워크 위에 구축된 인증 계층이다. OAuth 2.0이 인가(권한 부여)에 초점을 맞춘 반면, OIDC는 사용자가 누구인지 확인하는 표준화된 인증 방법을 제공하는 것이 핵심 목적이다. 간단히 말해, OAuth 2.0은 "이 앱이 내 정보에 접근할 수 있는 권한을 부여한다"는 데 사용되고, OIDC는 "이 앱에 내가 누구인지 증명한다"는 데 사용된다.

OIDC의 핵심은 ID 토큰이다. 이 토큰은 JWT 형식으로 발행되며, 사용자의 신원 정보(클레임)를 안전하게 전달한다. ID 토큰에는 일반적으로 발행자(iss), 대상자(aud), 만료 시간(exp)과 함께 사용자의 고유 식별자(sub), 이메일, 이름 등의 정보가 포함된다. 클라이언트는 이 토큰의 서명을 검증하여 발행자를 신뢰하고, 내부 정보를 해석하여 사용자를 인증한다.

OIDC는 몇 가지 표준 엔드포인트와 발견 메커니즘을 정의하여 상호운용성을 높인다. 인가 서버는 /.well-known/openid-configuration 엔드포인트를 통해 자신이 지원하는 설정(발행자 정보, 엔드포인트 URL 목록, 지원하는 알고리즘 등)을 JSON 형식으로 제공한다. 이를 통해 클라이언트는 서버의 기능을 동적으로 발견하고 구성할 수 있다.

OAuth 2.0과 OIDC의 관계는 다음 표로 정리할 수 있다.

OIDC는 소셜 로그인, 엔터프라이즈 싱글 사인온(SSO) 등 다양한 시나리오에서 사용자 인증의 표준으로 자리 잡았다. 액세스 토큰으로 리소스 서버에 접근 권한을 부여하는 OAuth 2.0의 기능을 그대로 유지하면서, 표준화된 방식으로 사용자 신원을 확인할 수 있게 해준다.

API 게이트웨이는 클라이언트와 백엔드 마이크로서비스 사이에 위치한 단일 진입점으로, 라우팅, 로드 밸런싱, 모니터링 등의 기능을 제공한다. 인증 및 인가 메커니즘과의 연동은 API 게이트웨이의 핵심 기능 중 하나이다. 게이트웨이 수준에서 JWT 또는 OAuth 2.0 액세스 토큰을 검증함으로써, 개별 서비스들이 인증 로직을 중복 구현할 필요가 없어지고 보안 정책을 일관되게 적용할 수 있다.

일반적인 연동 패턴은 다음과 같다. 클라이언트가 API를 호출할 때 HTTP 요청의 Authorization 헤더에 Bearer 토큰을 담아 전송한다. API 게이트웨이는 이 요청을 가로채 토큰의 서명을 검증하고, 필요한 경우 토큰 내부 클레임을 확인하여 인가 정책을 적용한다. 유효하지 않거나 권한이 없는 토큰에 대해서는 게이트웨이 단계에서 401 Unauthorized 또는 403 Forbidden 응답을 즉시 반환하여 백엔드 서비스로의 불필요한 트래픽을 차단한다. 검증이 완료된 토큰의 페이로드 정보는 종종 X-User-Claims와 같은 사용자 정의 헤더로 변환되어 다운스트림 서비스로 전달된다.

이러한 아키텍처는 몇 가지 명확한 장점을 제공한다. 첫째, 보안 관심사가 게이트웨이에 집중되어 백엔드 서비스는 순수한 비즈니스 로직에만 집중할 수 있다. 둘째, 토큰 검증과 같은 무거운 연산을 한 곳에서 처리함으로써 시스템 전체의 성능 효율성을 높일 수 있다. 셋째, 새로운 서비스가 추가되더라도 게이트웨이의 정책 설정만으로 일관된 인증/인가를 보장할 수 있어 확장성이 뛰어나다.

그러나 주의할 점도 존재한다. 게이트웨이가 단일 장애점이 될 수 있으며, 게이트웨이 구성이 복잡해질수록 관리 부담이 증가한다. 또한, 매우 세분화된 사용자 단위의 인가는 여전히 개별 서비스 내부에서 처리해야 할 수 있다. API 게이트웨이를 OAuth 2.0의 리소스 서버 역할로 구성하거나, 토큰 교환을 통해 내부 서비스 간 통신에 사용할 전용 토큰을 발급하는 고급 패턴으로 활용하기도 한다.