[Spring Security] OAuth2로 외부 사이트 계정으로 손쉽게 인증하기 (1) - 이론 및 설정 편

2025-03-11 12 분 소요

웹 사이트들을 돌아다니다보면 종종 구글, 네이버, 카카오 등을 이용한 소셜 연동 로그인을 통해 손쉽게 로그인할 수 있는 기능을 제공해주는 사이트들이 많은 것을 볼 수 있다. 이것도 물론 개발자가 자신이 개발하는 사이트에 연동하도록 구현할 수 있는데, 이를 가능케 하는 개념이 OAuth이다. 이 글에서는 OAuth란 무엇인지, 그리고 어떻게 구글, 네이버 등의 제 3자에게 인증, 인가 부분을 위임하여 개발자가 만든 사이트 내에서도 사용자가 인증된 상태로 보호된 자원에 접근하게 할 수 있는지 그 과정에 대해 살펴보겠다. 또한 이를 Spring Security와 연관된 OAuth2-Client라는 의존성을 통해 소셜 계정 연동 로그인을 어떻게 구현할 수 있는지에 대해 살펴보겠다.

OAuth2의 개념

OAuth(Open Authorization)는 application에 대한 사용자의 인증, 인가를 구글, 네이버 등의 제 3의 외부 제공자(provider)들에게 대신 위임하기 위해 사용되는 개방형 표준 인가 프로토콜이다. 좀 더 엄밀하게 정의하면 다음과 같이 알려져 있다.

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹 사이트 상의 자신들의 정보에 대해 웹 사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는 접근 위임을 위한 개방형 표준이다.

즉, 사용자들은 자신들이 사용하고자 하는 웹 사이트(또는 애플리케이션) 자체에서 회원 가입 및 로그인하는 대신 구글, 네이버 등의 제 3자에서 대신 로그인을 하여 웹 사이트의 접근 권한을 얻는 방식인 것이다. 그리고 이를 위해 공통적으로 정해진 표준 프로토콜이 OAuth이다.

OAuth를 이용하여 제 3자에서 대신 로그인을 거치면 사용자와 사용자가 사용하려는 애플리케이션, 그리고 구글, 네이버 등의 제 3자들은 각각 다음의 장점들을 얻게 된다.

사용자 : 애플리케이션에 회원 가입 하지 않아도 이미 가지고 있는 구글, 네이버 등의 계정과 연동하여 사용할 수 있어 편리하다. 보통 사람들은 정말 많은 웹 사이트에 회원가입하여 사용하기에 신경써야 할 계정들도 많을 것인데, 이미 보유하고 있는 구글, 네이버 등의 계정을 사용하여 웹 사이트에 접근 가능하다면 사용자의 계정 관리에도 용이할 것이다. 또한 애플리케이션 자체에 인증을 위한 패스워드 등의 민감 정보를 남기지 않아도 되기 때문에 설령 애플리케이션을 완전히 신뢰할 수 없다고 해도 사용자의 민감 정보는 구글, 네이버 등의 제 3자가 관리하기에 보안적 측면에서 걱정하지 않아도 될 것이다.
애플리케이션 : 일일이 회원 가입 기능을 구현하지 않아도 된다. (물론 애플리케이션 자체 회원 가입과 제 3자 연동 로그인 모두 제공하는 사이트들도 적지 않긴 하다) 또한 사용자의 패스워드와 같은 민감 정보들을 애플리케이션 자체가 책임을 맡고 관리하지 않아도 구글, 네이버 등의 제 3자가 대신 책임을 지기에 보안적 책임에서 비교적 자유롭다고 할 수 있겠다.
구글, 네이버 등의 제 3자 : 원래는 사용자의 개인 정보에 접근하려는 애플리케이션이 신뢰할 수 있는 곳인지 확인하기 어렵다(애플리케이션이 악의적인 의도를 가진 악성 웹 사이트일지도 모르잖은가). 하지만 OAuth 프로토콜을 이용하면 신뢰할 수 있는 애플리케이션에 대해서만 인증, 인가 기능을 부여해줄 수 있다.

OAuth의 1.0 버전에서는 보안적인 이슈가 있다고 한다. 그래서 현재는 이를 보완한 OAuth 2.0 버전을 사용한다고 한다. 필자가 조사해봤을 때, OAuth를 말하면 보통 OAuth 2.0에 대해서만 언급하였다. 따라서 이 글에서도 OAuth라 함은 2.0 버전을 기준으로 한다는 것을 미리 알린다.

OAuth에서 사용되는 용어, 개념들을 정리하면 다음과 같다.

용어	설명
Resource	사용자의 개인 정보를 의미한다.
Resource Owner (리소스 오너)	자신의 개인 정보(Resource)를 보유한 사용자를 의미한다. Authorization Server에 자신의 resource 접근을 허가하는 주체이기도 하다.
Resource Server (리소스 서버)	Resource Owner의 resource를 보유하고 있는 서버
Authorization Server (권한 서버, 인증 서버)	Client Application에게 Resource Owner가 보유한 Resource로의 접근 권한을 부여하는 주체이며, 이를 위해 토큰을 발급해주는 서버. Client Application을 대신하여 사용자 인증, 인가를 위임받아 처리하는 서버이다.
Client Application (클라이언트 애플리케이션, 그냥 줄여서 Client라고도 한다)	회사 또는 개인 개발자가 만든 애플리케이션 서버. 스프링 부트 등의 수단으로 개발한 서버가 이에 해당.

여기서의 클라이언트란 말은 애플리케이션 서버가 사용자의 리소스의 접근 권한을 얻기 위해 권한 서버에 요청하는 방식이기에 권한 서버가 “서버”의 입장이 되고, 애플리케이션 서버가 “클라이언트”의 입장이기에 붙여진 용어라고 한다. 그런데 평소에 사용하던 클라이언트-서버 관계에서의 클라이언트(사용자 또는 브라우저)와 헷갈리기에 이 글에서는 앞으로 권한 서버에 사용자의 리소스를 요청하는 애플리케이션 서버를 간단하게 클라이언트 앱이라 하겠다. 그리고 브라우저, 사용자를 지칭할 때에는 클라이언트라는 용어의 사용을 자제하고 직접적으로 브라우저, 리소스 오너 등의 용어를 사용하도록 하겠다.

리소스 서버는 사용자의 개인정보를 보유하고 있으며, 리소스 오너가 특정 클라이언트 앱의 리소스 접근 권한을 동의한 경우에 한해서만 해당 클라이언트 앱에 리소스를 제공하는 역할을 한다. 반면 권한 서버는 클라이언트 앱에게 리소스 접근 권한을 부여하는 역할을 하는 서버이다. 즉 이 두 서버는 역할이 서로 다르다. 하지만 이 두 서버 모두 클라이언트 앱의 입장에서는 제 3의 서버이다. 실제로 구글, 네이버 등의 회사에서는 이 두 서버를 모두 자회사에서 운영하는지, 아니면 권한 서버만 또 다른 회사에 위임하여 운영하는지는 모르겠지만 여기서는 두 서버 모두 구글, 네이버 등의 회사에서 자체적으로 소유, 관리한다고 가정하겠다.

한 편, OAuth를 이용하여 리소스 오너의 리소스를 클라이언트 앱이 취득하는 방법에도 다음과 같이 크게 4가지가 있다고 한다.

권한 부여 코드 승인 타입 (Authorization code grant type) : OAuth 2.0에서 잘 알려져 있고 보안적으로도 가장 안전한 방법이라 자주 쓰이는 인증 방식이라고 한다. 클라이언트 앱이 리소스에 접근할 권리를 얻기 위해 권한 서버로부터 권한 코드를 부여받고, 이를 액세스 토큰과 교환하여 리소스를 얻는 방식.
암시적 승인 타입 (Implicit grant type) : 백엔드 서버 없이 프론트엔드만 존재하는 자바스크립트 기반 웹 애플리케이션에서 사용하는 방식으로, 앞선 권한 부여 코드 승인 타입과 달리, 리소스 접근 권한 취득을 위해 별도의 권한 코드 교환 등의 인증 과정을 거치지 않고 바로 액세스 토큰을 제공받는 방식.
리소스 소유자 암호 자격증명 승인 타입 (Resource owner password credentials grant type) : 리소스 오너가 패스워드를 제공함으로써 리소스 접근을 위한 액세스 토큰을 교환받는 방식.
클라이언트 자격증명 승인 타입 (Client credentials grant type) : 클라이언트 앱이 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스의 접근을 요청하는 방식. 여기서 컨텍스트 외부라는 것은 사용자의 개입없이 인증이 진행된다는 뜻으로, 주로 서버 또는 서비스 간 통신에 사용되는 방식.

OAuth의 정의에 “프로토콜”, 즉 규약이란 말이 들어가 있듯, 구글, 네이버 등의 제 3자에게 인증, 인가를 대신 하도록 하는 과정에도 정해진 규약이 있다는 뜻이다. 따라서 OAuth를 이용하여 제 3자에 인증, 인가를 위임하는 과정에 대해 살펴보겠다. 이 글에서는 가장 많이 사용하는 방식인 권한 부여 코드 승인 타입에 대해서만 다루겠다.

권한 부여 코드 승인 타입을 통한 인증 과정

다음은 권한 부여 코드 승인 타입(Authorization code grant type)을 통한 인증 과정을 그린 그림이다.

그림 1-1. 권한 부여 코드 승인 타입 방식을 이용한 인증 방식.

위 과정을 차례대로 살펴보면 다음과 같다.

리소스 오너는 클라이언트 측에서 제공하는 웹 사이트에서 구글, 네이버 등 제 3자 사이트로 로그인할 수 있는 버튼을 누름으로써 로그인 요청을 한다. 이 때 로그인 요청은 권한 서버로 바로 가는 것이 아니라 먼저 클라이언트 앱 서버(스프링 부트 등을 이용하여 백엔드 개발자가 개발한 백엔드 서버)를 통하도록 한다.
클라이언트 앱 서버에서는 리소스 오너에게 로그인 페이지를 전달할 수 있도록 권한 서버로의 요청을 생성한다. 이 때, 클라이언트 ID, 인증 완료 후 클라이언트 앱으로 리다이렉트될 redirect uri, 응답 타입 등을 생성하여 요청에 포함시킨다. 보통 다음과 같은 형식으로 요청 URL이 생성된다고 한다.
```
 GET http://authorization-server/authorize?
 	client_id=(클라이언트 앱을 고유하게 식별할 수 있는 아이디)&
 	redirect_uri=http://localhost:8080/login/oauth2/code/google&
 	response_type=code&
 	scope=profile
```
여기서 사용된 각 파라미터들은 다음과 같다.
- client_id : 권한 서버 입장에서는 연동 로그인을 요청하는 수많은 클라이언트 앱들이 존재한다. 이들을 고유하게 식별하기 위해 권한 서버가 클라이언트 앱에 부여하는 고유 아이디이다.
- redirect_uri : 사용자의 인증 성공 후, 권한 서버가 클라이언트 앱 서버에 권한 코드를 부여하기 위한 리다이렉트 URL. 개발용 서버의 경우 보통 http://localhost:8080으로 시작될 것이다.
- response_type: 클라이언트 앱이 권한 서버로부터 받기 원하는 응답 타입. 여기서는 권한 코드를 권한 서버로부터 받을 것이므로 code 타입을 선택한다.
- scope : 제공받고자 하는 리소스 범위를 의미한다. 사용자의 아이디, 프로필, 이메일 주소 등 여러가지가 있다.
즉, 클라이언트 앱 서버에서 생성하는 URL은 권한 서버로부터 사용자에게 보여줄 로그인 페이지의 요청임과 동시에 사용자 인증 성공 시 클라이언트 앱이 권한 서버로부터 권한 코드를 얻기 위한 요청이기도 하다. 참고로, 이 요청을 받게 되는 권한 서버는 client_id와 redirect_uri를 통해 권한 서버가 신뢰할 수 있는 승인된 클라이언트 앱 서버로부터 온 요청인지, 아니면 신뢰할 수 없는 전혀 엉뚱한 서버가 보내온 것인지 구별할 수 있어 권한 서버의 클라이언트 앱 서버에 대한 인증에도 사용되는 셈이다. 위에서 언급한 요청 URL 생성 이후 클라이언트 앱 서버는 다시 브라우저에게 응답을 한다.
클라이언트 앱 서버로부터 응답받은 브라우저 측에서는 해당 응답에 포함된 리다이렉트로 인해 자동으로 권한 서버로 요청을 전송한다.
여기서 권한 서버는 그에 대한 응답으로 사용자에게 로그인 페이지를 보여준다. 만약 권한 서버로의 요청이 처음일 경우, 권한 서버에서는 사용자에게 이 클라이언트 앱이 사용자의 리소스에 접근하도록 허용할 것인지 동의 여부를 묻는다. 이 과정은 최초에 딱 한 번만 진행되며, 이후에는 바로 로그인 페이지가 보여지도록 한다. 사용자가 이에 동의하면 그 후 로그인 페이지가 보인다.
여기서 사용자는 사용자 이메일이나 닉네임, 그리고 패스워드를 입력하여 인증을 권한 서버에 요청한다.
로그인이 성공하면 권한 서버는 클라이언트 앱 서버에 제공할 권한 코드를 담은 요청 URL을 생성, 브라우저에 응답하여 자동으로 클라이언트 앱 서버로 리다이렉트하게끔 한다. 이 때 리다이렉될 URL은 앞서 클라이언트 앱 서버가 요청 정보에 담은 redirect_uri이다. 권한 서버가 클라이언트 앱 서버에 전달하게 될 권한 코드는 다음과 같은 형식으로 구성된다.
```
 GET http://localhost:8080/login/oauth2/code/google?code=authorization_code
```
권한 서버로부터 응답을 받은 브라우저는 자동으로 클라이언트 앱 서버로 리다이렉트된다. 결과적으로 클라이언트 앱 서버는 권한 서버로부터 권한 코드를 받게 된다. 이를 통해 클라이언트 앱 서버는 권한 서버에 직접 액세스 토큰 요청을 한다. (이 때에는 리다이렉션 없이 곧바로 클라이언트 앱 서버가 권한 서버에 요청을 한다) 클라이언트 앱 서버가 권한 서버에 보내는 요청은 주로 POST /token 형식의 다음과 같은 형태를 띤다.
```
 POST authorization-server/token
 {
     "cliend_id": "...",
     "client_secret" : "...",
     "redirect_uri": "http://localhost:8080/login/oauth2/code/google",
     "grant_type": "authorization_code",
     "code": "(권한 서버로부터 이전에 받은 권한 코드를 여기에 입력)"
 }
```
- client_secret : 사전에 미리 권한 서버로부터 부여받은 클라이언트 앱 서버의 패스워드. 앞서 말했듯, 권한 서버의 입장에서는 클라이언트 앱 서버가 과연 신뢰할 만한 서버인지 확인이 필요한데, 이를 인증하기 위한 수단이라 보면 되겠다. 사용자들도 웹 애플리케이션 이용을 위해 자신의 유저네임 및 패스워드를 입력하여 신뢰할 수 있는 사용자임을 인증받아야 하듯, 클라이언트 앱 서버도 권한 서버로부터 신뢰할 수 있는 서버임을 인증 받기 위한 수단인 셈이다.
- grant_type : 인증 타입. 여기서는 Authorization code grant type을 따르기에 “authorization_code”라 입력해야한다.
- code: 이전에 권한 서버로부터 부여받은 권한 코드를 여기에 입력한다.
이 요청을 받은 권한 서버는 요청 정보를 토대로 신뢰할 수 있는 클라이언트 앱 서버인지 검증 절차를 거친 후, 확인되었다면 액세스 토큰을 클라이언트 앱 서버에 응답한다.
권한 서버로부터 액세스 토큰을 발급받은 클라이언트 앱 서버는 리소스 서버에 해당 액세스 토큰과 함께 리소스 오너의 리소스를 요청한다. 리소스 서버는 해당 토큰을 검증하고, 검증되었으면 리소스를 클라이언트 앱 서버에게 응답한다. 다음은 클라이언트 앱 서버가 리소스 서버에 전달하는 요청 형식의 예이다.
```
 GET http://resource-server/userinfo
 Header: Authorization Bearer <Access-Token>
```

이 과정을 통해 최종적으로 클라이언트 앱 서버가 리소스 서버로부터 사용자의 개인정보를 얻어 사용자가 인증된 상태로 해당 웹 애플리케이션을 이용할 수 있게 된다.

이 과정을 통해 우리가 알 수 있는 사실들을 다음과 같이 추려낼 수 있겠다.

Authorization Code Grant Type에서는 인증 과정에서 총 두 번의 리다이렉션이 일어난다. 즉, 브라우저를 끼고 클라이언트 앱 서버와 권한 서버 두 서버 간의 인증을 위한 통신이 리다이렉션 기반으로 이뤄지는 것이다. 브라우저가 탁구 테이블이라면 두 서버는 서로 각자 반대편에서 탁구공을 탁구 테이블에 한 번씩 튕기면서 핑퐁하며 서로 주고받는 관계라 볼 수 있겠다.
클라이언트 앱의 입장에서는 신뢰할 수 있는 사용자인지 확인하기 위해 사용자에게 인증 과정을 요구할 수 있듯, 권한 서버의 입장에서도 클라이언트 앱이 신뢰할 수 있는지 확인이 필요하다는 것이다. 이를 위해 사전에 클라이언트 앱 개발자는 구글, 네이버 등의 개발자를 위한 사이트에 들어가 미리 자신의 앱을 등록하고, 권한 서버로부터 client id, client secret, 승인된 redirect uri 등을 얻어 권한 서버로부터 신뢰할 수 있는 앱임을 인증하는 과정이 필요하다는 것이다. 권한 코드도 이를 위해 나온 개념이다.

OAuth2 기반 로그인 구현을 위한 Google OAuth2 설정하기

이제부터는 외부 사이트의 계정과 연동하여 로그인 기능을 구현해보도록 해보곘다. 구글, 네이버, 카카오 등 여러 곳이 있지만 여기서는 구글 로그인에 대해서만 살펴보겠다. 앞서 언급했듯, 우리가 스프링 부트 등을 이용하여 개발할 클라이언트 앱 서버가 구글 등 제 3자 제공자의 권한 서버로부터 신뢰받기 위해선 우선 개발자는 사전에 미리 자신의 클라이언트 앱 서버를 등록하여 신뢰할 수 있는 사이트임을 등록하는 절차를 거쳐야 한다. 이를 통해 개발자는 최종적으로 권한 서버로부터 client id, client secret 등을 발급받아야 한다.

구글의 경우, 다음의 과정을 거친다.

우선 검색창에 Google Cloud Console이라 치고 해당 사이트에 방문한다. 그러면 처음에는 다음과 같은 화면이 보일 것이다. 구글 계정으로 로그인하지 않은 경우 먼저 로그인하고 온다.
처음 방문할 경우, 이 사이트에 생성, 등록한 프로젝트가 하나도 없기에 위와 같은 화면이 뜰 것이다. 프로젝트를 하나 생성해야 하기 위해 위 사진과 같은 화면에서 상단의 “프로젝트 선택” 버튼을 클릭한다.
새로 뜨는 창에서 우측 상단의 “새 프로젝트”를 클릭한다.
다음과 같은 창에서 프로젝트 명을 지어준다. 필자의 경우 다음 사진처럼 “google-oauth-test”라고 하였다. 작성 후 아래의 “만들기” 버튼을 클릭한다.
그 후 다시 처음의 화면으로 돌아오게 되는데, 앞서 본 “프로젝트 선택” 버튼을 다시 클릭해보면 다음과 같이 앞서 생성한 프로젝트가 목록에 존재하게 될 것이다. 이를 클릭한다.
그러면 다음과 같이 앞서 만든 프로젝트명이 뜨게 될 것이다.
좌측 최상단에 위치한 햄버거 버튼 클릭 후, [API 및 서비스] → [사용자 인증 정보] 클릭
다음의 화면이 보일텐데, 자세히 보면 OAuth 동의 화면을 구성해야 한다고 뜬다. “동의 화면 구성”을 클릭한다.

다음 화면에서 “시작하기” 버튼 클릭.
다음과 같은 화면이 뜰텐데, 먼저 개발자 자신이 개발하고 있는 클라이언트 앱 이름을 기입한다. 여기서는 간단히 “springboot-test”라 지었다. 그 아래에 있는 “사용자 지원 이메일”에도 자신의 이메일을 입력한다. 필자도 필자의 이메일을 입력하였다. 아래 사진에도 써져 있듯, “사용자가 동의에 대해 문의하는 용도”라고 하는데, 사용자의 개인 정보를 클라이언트 앱이 접근하도록 동의하는 것에 대해 사용자가 개발자에게 문의할 용도인 것 같다.
“대상”은 “외부”로 설정함으로써 외부 사용자들도 로그인 가능하게 한다. (여기서는 테스트 용이라 어차피 쓸 사람은 나밖에 없긴 하다)
[연락처 정보] → [이메일 주소] 란에 자신의 이메일을 입력한다. 그 후 “만들기” 버튼을 클릭한다.
그 후, 다음의 화면으로 이동될텐데, 이번에는 “OAuth 클라이언트 만들기” 버튼을 클릭한다.
다음의 화면에서 [애플리케이션 유형]에서는 [웹 애플리케이션]을 선택하였다. 이름은 자유롭게 준다. 필자는 ‘springboot-test”로 지었다.
아래로 스크롤 내리면 다음의 화면이 보일텐데, “승인된 리디렉션 URI”에 다음 사진처럼 “http://localhost:8080/login/oauth2/code/google”이라 입력한다.

만약 CSR 방식으로 프론트엔드와 백엔드를 분리하여 개발할 경우, “승인된 Javascript 원본”에는 프론트엔드 측의 도메인 URI을 입력하면 되겠다. 리액트를 이용할 경우 보통 개발용으로는 `http://localhost:3000”으로 주어질텐데 이를 기입하면 되겠다. 다 되었으면 하단의 파란색 “만들기” 버튼을 클릭한다.
그러면 다음과 같이 방금 생성한 “클라이언트”가 목록에 뜬다. 해당 목록을 클릭해보자.
그러면 다음과 같이 앞서 생성한 “클라이언트”의 정보가 보일 것이다. 여기서 우측의 “Additional Information”에 위치한 “클라이언트 ID”와 “클라이언트 보안 비밀번호”를 기억해둔다. 이는 스프링 부트를 이용하여 백엔드 개발 시 구글 연동 로그인을 구현하기 위해 필요한 정보들이다. 한 편, 해당 정보들이 외부로 노출되면 누군가가 이를 악용할 소지가 있기 때문에 노출되지 않도록 보안적으로 조심해야 한다.
다음은 클라이언트 앱 서버가 제공받을 사용자의 리소스 범위(scope)를 설정하는 과정이다. 방금 화면에서 좌측 사이드바 메뉴의 [데이터 액세스]를 클릭한다. 그러면 다음의 화면이 보일텐데, “범위 추가 또는 삭제” 버튼을 누르면 오른쪽 화면에 다음과 같이 사용자의 여러 종류의 리소스 목록들이 보일 것이다. 여기서는 간단하게 위 세 개의 항목만 추가하도록 하였다. 위 세 항목의 체크박스 클릭 후, 아래의 “업데이트”를 누르면 해당 창이 사라지고, 아래로 내려 “save”를 누르면 된다. 필자의 경우 이미 이를 설정해놨기 때문에 아래 사진처럼 “민감하지 않은 범위”에 필자가 설정한 리소스 범위가 목록에 포함되어 있다.