OAuth 2.0

OAuth란?

웹 서핑을 하다 보면 Google이나 kakao등의 외부 소셜 계정을 기반으로 간편히 회원가입 및 로그인할 수 있는 웹 어플리케이션을 쉽게 찾아볼 수 있다.

클릭 한 번으로 간편하게 로그인할 수 있을 뿐만 아니라, 연동되는 외부 웹 어플리케이션에서 제공해주는 기능을 간편하게 사용할 수 있다는 장점이 있다.

예를 들면 Google로 로그인을 하면 API를 통해 연동된 계정의 Google Calendar 정보를 가져와 사용자에게 보여줄 수 있다.

 

이 때 사용되는 프로토콜이 바로 OAuth다.

OAuth의 정의는 다음과 같다.

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

 

참고로 OAuth 2.0은 1.0에서 알려진 보안 문제 등을 개선한 버전이다.

 

OAuth 구성 요소

구분	설명
Resource Owner	웹 서비스를 이용하려는 유저, 자원(개인정보)을 소유하는 자, 사용자 'Resource' 는 개인정보라고 생각하면 된다.
Client	자사 또는 개인이 만든 애플리케이션 서버 클라이언트 라는 이름은 client가 Resource server에게 필요한 자원을 요청하고 응답하는 관계여서 그렇다.
Authorization Server	권한을 부여(인증에 사용할 아이템을 제공주는)해주는 서버다. 사용자는 이 서버로 ID, PW를 넘겨 Authorization Code를 발급 받을 수 있다. Client는 이 서버로 Authorization Code을 넘겨 Token을 받급 받을 수 있다.
Resource Server	사용자의 개인정보를 가지고있는 애플리케이션 (Google, Facebook, Kakao 등) 회사 서버   Client는 Token을 이 서버로 넘겨 개인정보를 응답 받을 수 있다.
Access Token	자원에 대한 접근 권한을 Resource Owner가 인가하였음을 나타내는 자격증명
Refresh Token	Client는 Authorization Server로 부터 access token(비교적 짧은 만료기간을 가짐) 과 refresh token(비교적 긴 만료기간을 가짐)을 함께 부여 받는다. access token은 보안상 만료기간이 짧기 때문에 얼마 지나지 않아 만료되면 사용자는 로그인을 다시 시도해야한다. 그러나 refresh token이 있다면 access token이 만료될 때 refresh token을 통해 access token을 재발급 받아 재 로그인 할 필요없게끔 한다.

출처: https://inpa.tistory.com/entry/WEB-📚-OAuth-20-개념-💯-정리 [Inpa Dev 👨‍💻:티스토리]

직접 사용자가 로그인 하는것이 아닌, 소셜 미디어로 로그인을 할 경우,

client(개인 서비스)는 Resource Owner(사용자)를 대신해 로그인 하는데, 이때 필요한 정보를 Resource Server(kakao, Google...)에서 얻어 서로 비교해 유효성을 판단한다.

client가 유저의 로그인정보와 자원을 Resource Server에 요청해 대신 로그인 하는 것이다.

 

이를 위해서는 client는 다음 단계를 가진다.

1. Resource Owner(사용자)로 부터 동의(허용)

2. Resource Server(로그인할 사이트)로 부터 client 신원확인

 

왜 그래야 하는지는 각각의 입장에서 생각을 해보면..

 

Resource Owner (유저) 입장

자신의 정보를 대신 사용하기 때문에 client가 어떤 정보를 활용하는지, 어떤 기능을 사용하려는지 모른다.

 

나쁜 마음을 가지면 개인정보를 마구잡이로 악용할수 있을 수도 있기 때문이다.

그러므로 client는 Resource Owner의 동의를 구해야 한다.

 

Resource Server(사이트) 입장

다른 사람의 일을 대신 해주는 사람이 정말 그 사람일지 궁금할 수 있다.

마찬가지로 Rewource Owner의 일을 수행 해주는 client가 정말 그 client일까 하는 물음이 있다.

 

그렇기 때문에 Resource Server는 Resource Owner의 브라우저를 통해 client를 구분하는 값(code)를 전달한다.

 

---

 

OAuth 서비스 등록해보기 (네이버 로그인), Resource owner 승인과정

https://inpa.tistory.com/entry/WEB-📚-OAuth-20-개념-💯-정리#oauth_서비스_등록해보기_네이버_로그인 

 

너무 좋은 정리글이 있어 읽어보며 너무 좋은 것 같아 가져와 봤다.

---

백엔드와 프론트엔드의 역할

그럼 어느정도 이해가 되었는데 프론트엔드와 백엔드 사이의 역할을 어떻게 나누어야 하냐는 점이 헷갈렸다.

 

여기저기 찾아보니

프론트에서도 OAuth가 가능하긴 하지만 이는 서버리스 상태에서 테스트용으로 사용하는거고 실 서비스에서 프론트가 로그인을 담당한다? 바로 망한다고 한다.

 

그리고 여기서 인증과 인가의 차이가 적용된다고 한다.

쉽게 말하면 인증은 요청, 인가는 권한 부여인데

요청은  kakao api같은 곳에서 호출해서 찌르는거고 권한부여는 토큰으로 db랑 비교해서 로그인 여부 결정을 해주는 것이다.

 

그런데 인가를 프론트에서 한다? 서버에는 로그인 기록이 남지않을 뿐더러 프론트에서 백으로 사용자 정보를 넘겨주면 탈취 가능성이 있다고 한다.

 

즉, 해결방법은

1. 프론트에서는 인증 요청을 하고 카카오로부터 받은 코드를 백에 넘겨준다.

2. 그럼 백에서는 받은 코드를 기반으로 카카오에 요청을 해서 토큰과 사용자 정보를 받아온다.

3, 해당 response를 기반으로 db값과 비교하여 인가 과정을 거치고 다시 프론트한테 200 상태코드를 전송해준다.