[백엔드] OAuth는 어떻게 진행되는가?

내가 처음 백엔드 개발할 때 담당했던 기능이 로그인, 그리고 GDG 프로젝트세션에 들어와서 처음 만진 것도 로그인, 그리고 이 블로그의 첫 글도 로그인..

 

그만큼 잘 까먹는 기능이기도하기 때문에 로그인 기능을 이번에 제대로 다져놓아보려한다.

---

다시, OAuth

OAuth란 무엇인가?

OAuth(Open Authorization)이란, 인터넷 사용자들이 한 웹사이트를 이용할 때, 해당 사이트가 다른 웹사이트에 있는 자신의 정보에 접근할 수 있도록하는, 인증을 위한 개방형 프로토콜이다.

 

대표적인 예시가 구글로그인, 네이버 로그인과 같은 소셜로그인 기능으로, 제 3의 웹사이트가 구글 또는 네이버에 있는 자신의 개인정보에 접근할 수 있도록 허가해주는 것을 말한다.

 

이외에도 웹사이트가 임의로 구글캘린더의 일정을 추가한다던가 하는 등, 한 사이트가 제 3의 사이트에 있는 사용자의 정보에 접근하는 방법을 정의한 프로토콜이다.

---

OAuth 구성원

1. Resource Owner

보호되는 리소스의 액세스 권한을 가지고 있는 사람이다. Resource Owner가 가지고 있는 정보가 OAuth 프로토콜을 통해서 가져올 정보다. 즉, 네이버 로그인 기능을 OAuth를 이용해 구현한다고하면 OAuth를 통해 네이버 로그인을 진행 중인 사용자가 이에 해당한다.

 

2. Client

OAuth 프로토콜을 사용해 Resource Owner의 정보에 접근할 애플리케이션 또는 서비스를 뜻한다. 즉, OAuth를 통해 사용자 정보에 접근하려는 프로그램

 

3. Authorization Server

클라이언트가 리소스 소유자의 정보를 얻을 수 있도록 중개해준다. 클라이언트가 리소스 소유자의 정보를 얻기 위해서 몇 가지 정보들이 필요한데, 이 정보의 유효성을 확인하고, 클라이언트가 리소스 소유자의 정보에 접근이 가능한지 등을 검사한다. 네이버 로그인에서 네이버 서버가 이 역할을 담당한다.

 

4. Resource Server

OAuth로 인증이 끝난 경우 실제로 클라이언트 측에 제공할 데이터가 저장된 서버에 해당한다.

---

OAuth 단계

https://guide.ncloud-docs.com/docs/b2bpls-oauth2 ❘ 문제 시 삭제

1. 사전 등록

만약 네이버나 구글 로그인 등, Resource Server의 정보에 접근해 OAuth 프로토콜을 구현할 것이라면 사전에 OAuth 프로토콜 사용요청을 보내고, 이후 OAuth에 사용할 key를 발급받는다.

 

2. 사용 요청 및 로그인

클라이언트는 리소스 소유자에게로부터 OAuth 프로토콜이 필요한 요청을 받게된다. 따라서 클라이언트 측은 이 요청을 받으면 OAuth 프로토콜이 실행되며, Authorization 서버 측으로 리소스 소유자의 정보에 접근하게 해달라는 승인 요청을 보내게된다.

 

이 때 그냥 승인 요청이 보내지는게 아니라 사전에 발급한 정보들이 포함되는데, 여기에는 클라이언트 ID와 비밀번호, 어떤 정보에 접근할 수 있는지에 대한 scope, redirect_url을 같이 넘긴다.

 

또한 Authorization 서버는 리소스 소유자로부터 클라이언트가 정보에 접근할 수 있는지 허가를 받아야하므로, 이 때 로그인 팝업창이 뜨고, 정보접근을 허가할 것인가에 대한 여부를 물어본다.

네이버에서 제공하는 로그인 API에 사전등록을 마치고나면 이렇게 클라이언트 ID와 비밀번호를 발급받고, redirect-url을 설정한다.

 

3. 토큰 발급

클라이언트는 리소스 소유자로부터 허가를 받았다고 마음대로 정보에 접근할 수 있는 것이 아니라, 한정된 유효기간을 갖고 있는 Access Token을 발급받아 정보에 접근할 때 제출해야한다.

 

클라이언트가 Authorization 서버 측으로 전달한 클라이언트 ID, 비밀번호, 스코프, redirect_url 들을 Authorization 서버는 사전에 등록한 정보와 일치하는지 대조하고, 하나라도 사전에 등록한 정보와 다를시 접근을 불허한다.

 

정보가 일치하다고 판단하면, Authorization 서버는 클라이언트가 사전에 등록한 redirect_url로 일회용 인증코드를 발급한다.

Authorization 서버는 redirect_url의 쿼리파라미터에 인증코드를 붙여서, 브라우저를 강제로 그 redirect_url로 이동시킨다. 그러니까 https://사전에등록한url?code=일회용인증코드 로 브라우저를 강제로 이동시킨다. 그리고 사전에등록한url은 클라이언트가 관리 중이다.

 

여기서 강제로 이동시킨다는 뜻은, redirect_url로 강제로 GET 요청을 보내라는 뜻이다. 따라서 클라이언트 측에서는 redirect_url로 요청이 들어오면 거기의 쿼리 파라미터를 확인하면 된다.

 

인증코드를 발급받았다면 인증코드와 함께 AccessToken 요청을 보내고, 최종적으로 AccessToken을 발급받는다.

---

스프링은?

사실 스프링으로 OAuth 개발을 하다보면 Authorization 서버 측으로 요청만 보내면 끝이 나는 경우가 많은데, 이는 이 이후 모든 과정을 스프링이 해주기 때문이다.

 

실제로 클라이언트 ID, 비밀번호 등 필요한 정보들은 개발자가 직접 헤더에 담아서 URL 요청을 보내야하고, 이후 정보 대조 같은 과정은 Authorization 서버 측에서 해주고, 이후 해야할 과정인 브라우저의 GET 요청을 받아서 인증코드를 확인한 후에 다시 Authorization 서버 쪽으로 요청을 보내는 일이 스프링이 담당하는 부분이다.