[인증] OAuth 2.0을 활용한 SNS 로그인

SNS 로그인 !== OAuth이다. 정확히 말하면 OAuth 프로토콜의 기능 중 하나로 SNS 로그인이 있는 것이다.

 

OAuth

OAuth란, 외부서비스의 인증 및 권한부여를 관리하는 범용적인 프로토콜이다.

• 권한: OAuth는 인증뿐만 아니라 권한도 관리한다. 사용자의 권한에 따라 접근할 수 있는 데이터가 다르도록 설정이 가능하다.
• 프로토콜: 일종의 규격이다. Google, Facebook, Naver, Kakao 등은 OAuth라는 규격에 맞춰 인증 및 권한을 대행관리 해준다.
• 외부서비스: 우리가 만들고 있는 서비스를 말한다. 외부 서비스를 위한 서비스인 OAuth는 우리 서비스의 인증 및 권한부여 관리를 대행해준다.

OAuth가, 처음에 포스팅했던 세션/쿠키 및 토큰 기반 인증 방식을 완전히 대체하는 게 아니기 때문에, SNS 로그인 기능을 넣더라도 결국은 세션/쿠키 및 토큰을 활용해 인증을 거쳐야 한다.

 

OAuth 2.0

현재 사용중인 OAuth의 대부분은 2.0 버전이다.

2012년 제시된 이후 지금까지 사용중인데, OAuth 2.0에서 크게 바뀐 점은 다음과 같다.

1. 모바일 어플리케이션에도 사용이 용이해짐
2. 반드시 HTTPS를 사용하기에 보안이 강화됨
3. Access Token의 만료기간이 생김

OAuth 2.0의 인증 방식은 크게 4가지이다.

1. Authorization Code Grant
2. Implicit Grant
3. Resource Owner Password Credentials Grant
4. Client Credentials Grant

1번이 가장 많이 쓰인다.

OAuth 2.0의 동작순서

출처: https://tansfil.tistory.com/60?category=475681

Resource Owner: 유저를 칭함. 일반 사용자.

Client: 우리가 만드는 서비스에 관련된, 어플리케이션 서버

Authorization Server: 권한을 관리하는 서버. Access Token과 Refresh Token을 발급 및 재발급해주는 역할

Resource Server: OAuth 2.0을 관리하는 서버(Google, Facebook, Kakao 등)의 자원을 관리하는 서버. 우리가 만드는 서버의 자원을 관리하는 곳이 아니라, OAuth 2.0 관리 서버의 자체 API를 의미한다.

출처: https://tansfil.tistory.com/60?category=475681

1. Resource Owner(사용자)가 Client(우리 서버)에게 인증 요청을 한다.
2. Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(Google 로그인, Facebook 로그인 URL)을 보낸다.
3. Resource Owner는 해당 Request를 통해 인증을 진행하고, 인증을 완료했다는 신호로 Authorization Grant를 URL에 실어 Client에게 보낸다.
4. Client는 해당 Authorization Grant(권한증서)를 Authorization Server에 보낸다.
5. Authorization Server는 권한증서를 확인한 후, 유저가 맞다면 Client에게 Access Token, Refresh Token, 그리고 유저의 프로필 정보(id 포함) 등을 발급해준다.
6. Client는 해당 Access Token을 DB에 저장하거나 Resource Owner에게 넘긴다.
7. Resource Owner가 Resource Server에 자원이 필요하면, Client는 Access Token을 담아 Resource Server에 요청한다.
8. Resource Server는 Access Token이 유효한지 확인한 후, Client에게 자원을 보낸다.
9. 만일 Access Token이 만료됐거나 위조됐다면, Client는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급받는다.
10. 그 후 다시 Resource Server에 자원을 요청한다.
11. 만일 Refresh Token도 만료되었을 경우 Resource Owner는 새로운 Authorization Grant를 Client에게 넘겨야한다. (이는, 사용자가 다시 로그인을 해야된다는 뜻이다.)

Access Token + Refresh Token을 이용한 인증 방식과 OAuth 인증 방식의 차이점은, 전자는 한 서버에서 모두 관리하는 반면에 후자에서는 Authorization Server에서 인증+권한 관리를 하고 Resource Server에서는 자원에 대한 관리만 한다는 점이다.

 

OAuth 2.0은 (사용자 - 서버)의 구조가 아닌, (사용자 - 서버 - OAuth 서버)의 구조이다. 우리가 만들 서비스들의 인증을 돕기 위한 서비스가 바로 OAuth이다. Resource Server는 우리의 서버가 아닌 OAuth를 관리하는 서버의 일부임을 명심해야한다.

 

SNS 로그인을 제공하는 Google, Facebook, Kakao 등은 모두 OAuth 2.0 프레임워크를 통해 로그인 API를 제공하므로 OAuth 2.0에 대한 정보가 필수적이다.

 

SNS 로그인

SNS 로그인은, 간단하게 봤을 때 OAuth 2.0 + 서버 인증(세션/쿠키, 토큰 기반 인증)으로 구성된다.

예시는 Facebook 로그인으로 든다.

 

출처: https://tansfil.tistory.com/60?category=475681

1. 사용자(Resource Owner)가 서버에게 로그인을 요청한다.
2. 서버는 사용자에게 특정 쿼리들을 붙인 페이스북 로그인 URL을 사용자에게 보낸다.
3. 사용자는 해당 URL로 접근하여 로그인을 진행한 후 권한증서(code)를 담아 서버에게 보낸다.
4. 서버는 해당 권한 증서(Authorization Grant)를 Facebook의 Authorization Server로 요청한다.
5. 서버는 권한 증서를 확인한 후 Access Token, Refresh Token, 유저의 정보(고유 id 등을 포함) 등을 알려준다. ( 여기서 프로필 이미지나 이메일 주소, 이름 등을 얻을 수도 있는데, 이는 초기에 관리자가 권한 설정을 어디까지 하느냐에 따라 다르다.)
6. 받은 고유 id를 key값으로 해서 DB에 유저가 있다면 로그인, 없다면 회원가입을 진행한다.
7. 로그인이 완료되었다면 세션/쿠키, 토큰 기반 인증 방식을 통해 사용자의 인증을 처리한다.

- 우리가 만들 서버에서 OAuth를 이용하기 위해서는 사전에 OAuth를 등록하는 과정이 필요하다. 등록 후 API_ID와 CLIENT_ID 등을 보내야 OAuth에서는 어느 서비스인지를 알 수 있다.

- 페이스북 로그인을 인증하는 경우, 대부분은 Resource Server(페이스북 자체 API)를 사용하지 않는다. 따라서 Access Token, Refresh Token은 실제로 쓰이지 않는다. 우리의 서버에서 Access Token을 검증할 수도 없을 뿐더러 수단으로 활용하기엔 부족한 점이 많다. 따라서 보통 7번 절차처럼 Authorization Server로부터 얻는 고유 id값을 활용해서 DB에 회원관리를 진행한다.

 

장점

1. 회원가입이라는 귀찮은 절차를 없애고, 사용자가 빠르게 회원가입을 할 수 있다.
2. 접근하고 싶은 정보들은 사용자들이 미리 권한 내용을 확인하고 허락하기에 쉽게 접근할 수 있다.

이렇게 세션/토큰 인증방식부터 Access Token과 Refresh Token에 기반한 JWT 방식, 그리고 이 두 가지를 합친 OAuth 2.0까지 알아봤다. 내일은 이렇게 배운 개념을 토대로 React에 OAuth 2.0을 적용해 볼 것이다.