오늘날의 웹 애플리케이션에서는 사용자가 자신의 데이터를 다른 서비스와 연동하여 작업할 수 있어야 합니다. 예를 들어, 사용자가 우리 서비스에서 구글 캘린더에 일정을 추가하거나 페이스북에 글을 게시할 수 있습니다. 이러한 기능을 구현하는 가장 쉬운 방법은 사용자의 구글, 페이스북 ID와 비밀번호를 받아 직접 저장하고 사용하는 것이겠지만, 이는 보안상 매우 위험한 방식입니다.
OAuth의 등장 배경
초기에 웹 서비스는 사용자의 비밀번호를 직접 저장해 타사 서비스를 대신해서 사용하곤 했습니다. 그러나 이는 사용자 정보 유출의 위험을 증가시키고, 보안 사고가 발생할 경우 큰 피해를 초래할 수 있습니다. 이를 방지하기 위해 각 서비스는 자체 인증 방식을 개발했으나, 이 방식은 표준화되지 않아 개발자들이 각기 다른 인증 시스템에 맞춰 개발해야 했습니다.
이 문제를 해결하기 위해 등장한 것이 바로 OAuth입니다. OAuth는 사용자 정보를 안전하게 보호하면서도 타사 서비스가 사용자를 대신해 그 정보를 활용할 수 있게 해주는 표준 인증 프로토콜입니다. OAuth는 사용자 비밀번호를 제3자에게 제공하지 않고도 안전하게 사용자 정보를 활용할 수 있는 방식을 제공합니다.
OAuth 2.0과 OpenID Connect의 개요
OAuth 2.0은 권한 부여(Authorization)에 중점을 둔 프로토콜입니다. 사용자가 제3자 서비스가 자신의 데이터를 접근할 수 있도록 권한을 부여하는 시스템으로, 사용자의 비밀번호를 제공하지 않으면서도 안전하게 데이터를 관리할 수 있습니다.
반면, OpenID Connect는 OAuth 2.0을 확장한 인증(Authentication) 프로토콜입니다. 이는 사용자의 신원 확인에 중점을 두고 있으며, OAuth 2.0 흐름에 더해 ID Token을 발급해 사용자의 인증 정보를 전달합니다. 이 ID Token은 JWT(JSON Web Token) 형식으로, 사용자 ID, 이메일 등 인증 정보를 포함할 수 있습니다.
OAuth 2.0의 주요 개념
- 리소스 소유자 (Resource Owner): 데이터를 소유한 사용자입니다. 예를 들어, 사용자의 구글 캘린더 데이터가 이에 해당합니다.
- 클라이언트 (Client): 리소스 소유자의 데이터를 접근하려는 서비스로, 우리의 웹 애플리케이션이 이 역할을 수행합니다.
- 인증 서버 (Authorization Server): 사용자를 인증하고 클라이언트에 Access Token을 발급하는 서버로, 구글 또는 페이스북과 같은 서비스가 해당됩니다.
- 리소스 서버 (Resource Server): 데이터를 보유하고 있는 서버로, 클라이언트가 접근할 리소스를 제공합니다. 예를 들어, 구글 캘린더 서버가 이에 해당합니다.
OAuth 2.0의 동작 원리
OAuth 2.0은 다양한 인증 흐름을 제공하지만, 여기서는 가장 많이 사용되는 Authorization Code Grant Flow를 중심으로 설명합니다. 이 흐름은 클라이언트가 사용자를 대신해 데이터에 접근할 수 있도록 권한을 받는 안전한 방법입니다.
1. 사용자 로그인 요청
사용자가 구글 소셜 로그인을 요청하면, 프론트엔드는 구글의 인증 서버로 사용자를 리디렉션합니다. 이때 프론트엔드는 client_id, redirect_uri, scope, response_type 등을 포함한 Authorization URL을 구성합니다.
2. 사용자 인증 및 권한 승인
사용자는 구글의 로그인 페이지에서 자신의 계정으로 로그인하고, 클라이언트가 요청한 권한을 승인합니다. 예를 들어, 이메일이나 프로필 정보에 대한 접근 권한을 승인할 수 있습니다.
3. Authorization Code 발급 및 리디렉션
인증이 완료되면 구글은 설정된 redirect_uri로 Authorization Code를 전달합니다. 이 코드는 일회성으로 짧은 시간 동안만 유효하며, 클라이언트는 이 코드를 사용해 Access Token을 요청할 수 있습니다.
4. Authorization Code와 Access Token 교환
Authorization Code는 백엔드가 수신합니다. 백엔드는 이 코드를 구글의 토큰 엔드포인트로 전송해 Access Token을 요청합니다. 이때 client_id, client_secret도 함께 전송됩니다.
5. Access Token 발급 및 사용자 정보 요청
구글은 백엔드에 Access Token을 발급합니다. 이 토큰은 사용자가 승인한 구글 리소스에 접근할 수 있는 권한을 나타냅니다. 백엔드는 이 Access Token을 사용해 구글 API로부터 사용자 정보를 요청할 수 있습니다.
6. 사용자 로그인 완료
백엔드는 구글로부터 받은 사용자 정보를 프론트엔드로 전달하고, 사용자는 구글 계정으로 인증된 상태에서 애플리케이션을 사용할 수 있게 됩니다.
구글 소셜 로그인 과정: OAuth 2.0과 OpenID Connect의 적용
OAuth 2.0과 OpenID Connect를 이용한 구글 소셜 로그인 과정은 다음과 같습니다:
-
사용자 로그인 요청: 사용자가 "구글로 로그인" 버튼을 클릭하면, 프론트엔드는 구글 인증 서버로 사용자를 리디렉션합니다. 이때
client_id,redirect_uri,scope,response_type등을 포함한 URL이 사용됩니다. -
사용자 인증 및 권한 승인: 사용자는 구글 로그인 페이지에서 자신의 구글 계정으로 로그인하고, 클라이언트가 요청한 접근 권한을 승인합니다.
-
Authorization Code 발급 및 리디렉션: 구글은 설정된
redirect_uri로 Authorization Code를 전달합니다. 이 코드는 클라이언트가 Access Token을 발급받기 위해 사용됩니다. -
Authorization Code 전달: 프론트엔드는 이 Authorization Code를 백엔드로 전달합니다. 하지만 보안상의 이유로, 대부분의 경우 백엔드가 직접 이 코드를 받도록 설정하는 것이 더 안전합니다.
-
Access Token 발급 및 사용자 정보 요청: 백엔드는 구글로부터 Access Token을 발급받고, 이 토큰을 사용해 구글 API로부터 사용자의 프로필 정보를 요청합니다.
-
로그인 완료: 백엔드는 구글로부터 받은 사용자 정보를 프론트엔드에 전달하고, 사용자는 구글 계정으로 로그인된 상태로 애플리케이션을 사용할 수 있습니다.
보안 및 확장성 고려 사항
OAuth 2.0의 모든 중요한 트랜잭션은 HTTPS를 통해 수행되어야 합니다. Access Token은 민감한 정보이므로 반드시 HTTPS 연결을 통해 전송되어야 하며, 그렇지 않으면 중간자 공격에 취약할 수 있습니다. 또한, 클라이언트 시크릿(client_secret)은 백엔드에서만 안전하게 관리되어야 하며, 외부로 유출되지 않도록 주의해야 합니다.
OAuth의 장점과 유용성
OAuth 2.0은 사용자 비밀번호를 직접적으로 수집하지 않고도 안전하게 사용자 데이터를 관리하고 접근할 수 있는 방법을 제공합니다. 이를 통해 사용자와 타사 서비스 간의 신뢰를 강화하고, 보안 위협을 최소화할 수 있습니다. 또한 OAuth는 다양한 플랫폼 간의 연동을 표준화하여 확장성과 유지보수의 편리성을 크게 높입니다.
결론
OAuth 2.0은 사용자의 민감한 정보를 보호하면서도 클라이언트가 타사 서비스의 데이터를 안전하게 사용할 수 있도록 해주는 강력한 인증 프로토콜입니다. 특히 구글, 페이스북 등 대규모 플랫폼과의 연동에서 OAuth는 보안과 편의성을 제공하며, 서비스 확장을 위한 필수적인 도구가 되었습니다.
