안녕하세요! 개발자라면 한 번쯤은 ‘사용자 로그인 기능’이나 ‘다른 서비스 연동 기능’을 구현하면서 인증(Authentication)과 인가(Authorization)에 대해 고민해보셨을 거예요. 단순히 ID/PW로 로그인하는 것부터 시작해서, 소셜 로그인 연동이나 외부 API 접근 권한 부여까지, 이 모든 과정이 안전하고 효율적으로 이루어져야 하는데요. 복잡하고 민감한 작업이다 보니, 어디서부터 손대야 할지 막막할 때도 많죠? 😱
그래서 오늘은 여러분의 이러한 고민을 덜어드리고자, OAuth 2.0과 OpenID Connect를 활용하여 안전하고 견고한 인증/인가 시스템을 구축하는 방법에 대해 자세히 이야기해보려 합니다. 이 두 기술은 현대 웹과 모바일 환경에서 사용자 경험을 향상시키면서도 보안을 강화하는 데 필수적인데요. 과연 어떤 역할을 하고, 어떻게 함께 쓰이는지 궁금하시죠? 저와 함께 차근차근 알아보시죠!
📑 목차
Image by Myriams-Fotos on Pixabay
OAuth 2.0, 넌 누구니? 인가의 표준!
먼저 OAuth 2.0부터 살펴볼까요? OAuth는 'Open Authorization'의 약자인데요, 이름에서 알 수 있듯이 인가(Authorization)에 특화된 프레임워크입니다. 여기서 중요한 건 '프레임워크'라는 점인데요. 특정 프로토콜이나 기술 스택을 강제하기보다는, 인가 흐름을 구현하기 위한 일반적인 가이드라인을 제공한다고 이해하시면 됩니다.
쉽게 말해, 내 서비스(클라이언트)가 다른 서비스(리소스 서버)에 있는 사용자(리소스 소유자)의 특정 데이터(리소스)에 접근할 수 있는 권한(Access Token)을 안전하게 얻는 방법을 정의하는 거죠. 예를 들어, 여러분이 어떤 쇼핑몰 앱에서 '카카오톡으로 로그인'을 선택하면, 쇼핑몰 앱은 카카오톡에 직접 여러분의 아이디와 비밀번호를 요청하는 것이 아니라, 카카오톡 서버로부터 여러분의 프로필 정보나 친구 목록에 접근할 수 있는 권한만 부여받는 방식이에요. 사용자 입장에서는 비밀번호를 직접 공유할 필요가 없으니 훨씬 안전하겠죠?
OAuth 2.0의 핵심 구성 요소와 동작 방식
OAuth 2.0의 작동 방식을 이해하려면 몇 가지 핵심 구성 요소를 알아야 해요. 복잡하게 들릴 수 있지만, 그림으로 생각하면 아주 간단하답니다.
- 리소스 소유자 (Resource Owner): 데이터를 소유한 사용자입니다. 예를 들어, 카카오톡 사용자 본인이죠.
- 클라이언트 (Client): 리소스 소유자의 데이터에 접근하려는 애플리케이션 또는 서비스입니다. 위 예시에서는 쇼핑몰 앱이 되겠네요.
- 권한 부여 서버 (Authorization Server): 리소스 소유자의 동의를 얻어 클라이언트에게 접근 토큰(Access Token)을 발급해주는 서버입니다. 카카오톡의 인증 서버가 이 역할을 합니다.
- 리소스 서버 (Resource Server): 보호된 리소스(데이터)를 호스팅하는 서버입니다. 카카오톡의 사용자 프로필 정보를 제공하는 서버가 되겠죠.
이 네 가지 구성 요소가 어떻게 상호작용하는지 가장 흔한 권한 부여 코드(Authorization Code) 흐름을 예로 들어볼게요.
- 사용자가 클라이언트 앱에서 '소셜 로그인' 버튼을 누릅니다.
- 클라이언트는 권한 부여 서버로 사용자를 리다이렉트 시키고, 사용자에게 어떤 권한을 요청하는지 보여줍니다. (예: 프로필 정보, 이메일 주소)
- 사용자가 권한 부여 서버에서 로그인을 하고, 클라이언트 앱에 권한 부여를 '동의'합니다.
- 권한 부여 서버는 클라이언트에게 권한 부여 코드(Authorization Code)를 발급하고, 클라이언트가 미리 등록해 둔 리다이렉트 URI로 사용자를 다시 리다이렉트 시킵니다.
- 클라이언트는 이 권한 부여 코드를 권한 부여 서버로 다시 보내서 접근 토큰(Access Token)을 요청합니다. 이때 클라이언트의 비밀 정보(Client Secret)를 함께 보내 본인임을 인증하죠.
- 권한 부여 서버는 클라이언트의 요청이 유효하면 접근 토큰(선택적으로 갱신 토큰(Refresh Token)도 함께)을 발급합니다.
- 클라이언트는 이 접근 토큰을 가지고 리소스 서버에 접근하여 사용자의 정보를 요청합니다.
- 리소스 서버는 접근 토큰이 유효한지 확인하고, 유효하다면 요청된 리소스(사용자 정보)를 클라이언트에게 제공합니다.
이 과정에서 중요한 점은, 클라이언트는 사용자의 비밀번호를 전혀 알 필요가 없다는 거예요. 오직 접근 토큰만을 가지고 정해진 권한 내에서만 리소스에 접근할 수 있게 되는 거죠. 이로 인해 보안성이 크게 향상됩니다. 또한, 갱신 토큰을 통해 접근 토큰이 만료되어도 사용자의 재로그인 없이 새로운 접근 토큰을 발급받을 수 있어 사용자 경험도 좋아진답니다.
OpenID Connect, 왜 필요할까요? 인증의 확장!
자, 이제 OpenID Connect(OIDC) 차례입니다. OAuth 2.0이 인가(Authorization)를 위한 프레임워크라면, OIDC는 인증(Authentication)을 위한 프로토콜이라고 할 수 있어요. OIDC는 OAuth 2.0 위에 아이덴티티 레이어(Identity Layer)를 추가한 형태인데요, 이는 OAuth 2.0만으로는 사용자 '인증'을 수행하기에는 부족했기 때문입니다.
OAuth 2.0은 '누구'인지에 대한 정보(인증)보다는 '무엇을 할 수 있는지'에 대한 정보(인가)를 제공하는 데 초점을 맞춥니다. 그래서 클라이언트는 접근 토큰을 받아 리소스 서버에 요청을 해야만 사용자 정보를 얻을 수 있었죠. 하지만 소셜 로그인을 생각해보세요. 우리는 '누구'가 로그인했는지, 그 사용자의 이름이나 이메일 같은 아이덴티티 정보가 즉시 필요하잖아요? OIDC는 바로 이 부분을 해결해줍니다.
OpenID Connect의 핵심 요소: ID Token
OIDC의 핵심은 바로 ID 토큰(ID Token)입니다. OAuth 2.0의 접근 토큰이 리소스 접근 권한을 나타낸다면, ID 토큰은 사용자가 성공적으로 인증되었음을 증명하고, 사용자에 대한 정보를 담고 있는 JWT(JSON Web Token) 형식의 토큰이에요. 이 ID 토큰 안에는 다음과 같은 정보들이 담겨 있습니다.
- iss (Issuer): ID 토큰을 발급한 OpenID 공급자의 URL
- sub (Subject): OpenID 공급자 내에서 사용자를 고유하게 식별하는 식별자
- aud (Audience): ID 토큰을 받을 클라이언트의 ID (클라이언트가 누구인지)
- exp (Expiration Time): ID 토큰의 만료 시간
- iat (Issued At Time): ID 토큰이 발급된 시간
- 그 외 다양한 클레임(Claims): 사용자의 이름, 이메일, 프로필 사진 등
클라이언트는 ID 토큰을 받으면, 이 토큰의 유효성을 검증하고(서명 확인 등), 그 안에 담긴 클레임 정보를 바로 추출하여 사용자를 인증하고 필요한 정보를 얻을 수 있습니다. 별도로 리소스 서버에 요청할 필요 없이, 인증과 동시에 사용자 정보를 확보할 수 있게 되는 거죠. 이게 바로 OIDC가 제공하는 가장 큰 이점 중 하나입니다.
또한, OIDC는 UserInfo Endpoint라는 표준화된 엔드포인트도 제공합니다. ID 토큰에 담기지 않은 더 많은 사용자 정보가 필요할 경우, 클라이언트는 접근 토큰을 사용하여 UserInfo Endpoint에 요청을 보내 상세 정보를 얻을 수 있습니다. 이로써 싱글 사인 온(Single Sign-On, SSO) 환경을 구축하는 데도 매우 유리해진답니다.
Image by Tumisu on Pixabay
OAuth 2.0과 OpenID Connect, 무엇이 다를까요?
이제 두 기술의 차이점을 명확히 이해하는 것이 중요해요. 많은 분들이 이 둘을 혼동하시곤 하는데요, 간단하게 정리하자면 다음과 같습니다.
| 구분 | OAuth 2.0 | OpenID Connect |
|---|---|---|
| 목적 | 인가(Authorization): 리소스 접근 권한 부여 | 인증(Authentication): 사용자 신원 확인 |
| 무엇을 제공하는가 | 접근 토큰(Access Token) | ID 토큰(ID Token) (및 접근 토큰) |
| 주요 사용처 | API 접근 권한 부여, 3rd party 서비스 연동 | 소셜 로그인, 싱글 사인 온(SSO) |
| 관계 | 독립적인 인가 프레임워크 | OAuth 2.0 위에 구축된 인증 프로토콜 |
| 주요 정보 | 권한 범위(Scope) | 사용자 식별 정보(Claims) |
결론적으로, OAuth 2.0은 '네가 이 데이터에 접근할 수 있어'라고 허락해주는 역할을 하고, OpenID Connect는 '네가 바로 그 사람이야'라고 신원을 확인해주는 역할을 합니다. 이 둘은 서로를 보완하며 함께 사용될 때 강력한 시너지를 발휘하는 거죠. 대부분의 소셜 로그인 기능은 OAuth 2.0과 OIDC를 함께 사용하여 사용자 인증과 리소스 접근 권한 부여를 동시에 처리하고 있답니다.
Image by websubs on Pixabay
안전한 인증/인가 시스템 구축을 위한 실전 가이드
이제 이론적인 내용을 바탕으로 실제 시스템을 구축할 때 고려해야 할 실전적인 팁들을 알려드릴게요. 단순히 기능 구현을 넘어, 보안과 유지보수성을 높이는 데 초점을 맞춰보죠.
1. 클라이언트 등록 및 관리 철저히
여러분의 서비스가 OAuth 2.0/OIDC 클라이언트 역할을 한다면, 권한 부여 서버(IdP)에 클라이언트를 등록할 때 신경 쓸 부분이 많아요.
- 리다이렉트 URI (Redirect URI): 반드시 정확하고 안전한 URL만 등록해야 합니다. 예를 들어,
http://localhost나 특정 IP 주소 대신,https://your-service.com/callback과 같이 HTTPS를 사용하는 도메인 기반의 주소를 사용하고, 가능한 한 명시적으로 지정하여 예상치 못한 리다이렉션 공격을 방지해야 합니다. 여러 개의 URI가 필요하다면 모두 등록해야 하고요. - 클라이언트 ID (Client ID) / 클라이언트 시크릿 (Client Secret): 클라이언트 ID는 공개되어도 무방하지만, 클라이언트 시크릿은 절대 외부에 노출되어서는 안 됩니다. 서버 측 애플리케이션에서는 안전하게 환경 변수나 비밀 관리 시스템에 보관하고, 모바일 앱이나 SPA(Single Page Application)와 같이 클라이언트 시크릿을 안전하게 보관하기 어려운 환경에서는 PKCE(Proof Key for Code Exchange) 확장 기능을 적극적으로 활용해야 합니다. PKCE는 클라이언트 시크릿 없이도 권한 부여 코드 가로채기 공격을 방어할 수 있게 해주는 아주 유용한 보안 메커니즘이거든요.
- 스코프 (Scope) 관리: 클라이언트가 요청하는 권한(예:
profile,email,openid)은 최소한의 필요한 범위로만 지정해야 합니다. 과도한 권한은 잠재적인 보안 위험을 증가시키고, 사용자에게도 불필요한 정보 공유로 느껴질 수 있어요.
2. 토큰 관리 전략: 접근 토큰과 갱신 토큰
발급받은 토큰들을 어떻게 관리하느냐에 따라 시스템의 보안성과 사용성이 크게 달라집니다.
- 접근 토큰 (Access Token): 수명이 짧게(예: 1시간) 설정하는 것이 일반적입니다. 노출되더라도 피해를 최소화하기 위함인데요. 클라이언트 측에서는 이 토큰을 메모리에 저장하거나, 웹의 경우 HTTP Only & Secure 속성의 쿠키에 저장하는 것이 좋습니다. 로컬 스토리지에 저장하는 것은 XSS 공격에 취약할 수 있어 권장되지 않아요.
- 갱신 토큰 (Refresh Token): 접근 토큰보다 수명이 길지만(예: 며칠 또는 몇 주), 훨씬 민감한 정보이므로 더욱 안전하게 보관해야 합니다. 서버 측 애플리케이션에서는 DB에 암호화하여 저장하고, 모바일 앱에서는 키체인(Keychain)이나 안드로이드 키스토어(Keystore) 같은 플랫폼별 보안 저장소를 활용해야 합니다. 웹에서는 갱신 토큰을 HTTP Only & Secure 속성의 쿠키에 저장하는 것이 가장 일반적이고 안전한 방법이에요. 갱신 토큰을 사용해서 새로운 접근 토큰을 발급받을 때도, 항상 클라이언트 인증(Client ID/Secret 또는 PKCE)을 거쳐야 합니다.
- 토큰 폐기 (Token Revocation): 사용자가 로그아웃하거나, 보안상 문제가 발생했을 때는 즉시 접근 토큰과 갱신 토큰을 폐기할 수 있는 메커니즘을 구현해야 합니다. 권한 부여 서버(IdP)가 토큰 폐기 엔드포인트를 제공하는지 확인하고 활용하세요.
// 예시: Node.js에서 HTTP Only & Secure 쿠키 설정
res.cookie('refreshToken', refreshToken, {
httpOnly: true, // JavaScript에서 접근 불가
secure: true, // HTTPS에서만 전송
sameSite: 'Lax', // CSRF 방지
maxAge: 7 * 24 * 60 * 60 * 1000 // 7일 유효
});3. 보안 고려사항 및 모범 사례
안전한 시스템 구축을 위해 항상 염두에 두어야 할 몇 가지 사항들이 있습니다.
- HTTPS 사용: 모든 통신은 반드시 HTTPS를 통해 이루어져야 합니다. HTTP는 중간자 공격(Man-in-the-Middle Attack)에 취약하여 토큰이나 민감 정보가 가로채질 위험이 매우 높습니다.
- 입력 유효성 검사: 클라이언트로부터 받은 모든 입력(예: 리다이렉트 URI, 스코프 등)은 서버 측에서 철저하게 유효성을 검사해야 합니다. 예상치 못한 값이나 악의적인 스크립트 삽입을 방지하기 위함이에요.
- 에러 처리: 에러 메시지는 구체적인 정보를 외부에 노출하지 않도록 일반적이고 추상적으로 제공해야 합니다. 공격자에게 시스템 내부 정보를 흘리지 않기 위함입니다.
- JWT 서명 검증: OIDC의 ID 토큰은 JWT 형식인데, 반드시 서명(Signature)을 검증해야 합니다. 이를 통해 토큰이 위변조되지 않았음을 확인할 수 있어요. 대부분의 JWT 라이브러리는 이 기능을 제공합니다. 공개 키(Public Key)를 사용하여 검증하는데, OpenID 공급자가 제공하는
.well-known/openid-configuration엔드포인트에서 공개 키 정보를 얻을 수 있습니다. - Nonce 값 활용: OIDC 플로우에서는 Nonce 값을 사용하여 재전송 공격(Replay Attack)을 방지할 수 있습니다. 클라이언트가 임의의 문자열(Nonce)을 생성하여 인증 요청에 포함시키고, ID 토큰에 포함된 Nonce 값과 일치하는지 확인하는 방식입니다.
- CORS (Cross-Origin Resource Sharing): API 서버에서 CORS 설정을 적절하게 하여, 허용된 도메인에서만 접근할 수 있도록 제한해야 합니다.
마무리하며: 튼튼한 서비스의 초석
지금까지 OAuth 2.0과 OpenID Connect를 활용하여 안전한 인증/인가 시스템을 구축하는 방법에 대해 자세히 알아보았습니다. OAuth 2.0이 리소스 접근에 대한 인가를 담당하고, OpenID Connect가 사용자 인증과 아이덴티티 정보를 제공한다는 점, 그리고 이 둘이 함께 사용될 때 비로소 완벽한 보안과 편리함을 제공한다는 점을 기억하시면 좋을 것 같아요.
이러한 표준 기술들을 올바르게 이해하고 적용하는 것은 사용자 데이터를 보호하고, 서비스의 신뢰도를 높이는 데 매우 중요한 일입니다. 처음에는 복잡하게 느껴질 수 있지만, 핵심 개념과 동작 원리를 파악하고 나면 훨씬 수월하게 적용할 수 있을 거예요. 오늘 알려드린 실전 가이드들을 참고하셔서 여러분의 서비스에 튼튼하고 안전한 인증/인가 시스템을 구축하시길 바랍니다!
혹시 OAuth 2.0이나 OpenID Connect를 구현하면서 겪었던 재미있는 에피소드나, 더 유용한 팁이 있다면 댓글로 공유해주세요! 다음에도 더 유익한 정보로 찾아오겠습니다. 😊