OAuth 2.0 개념 정리

들어가며

 

OAuth 2.0이 실무, 사이드프로젝트에서 많이 사용했던 기술이지만 OAuth 2.0이 가진 요소와 개념들에 대해 명확하게 머리속으로 정리가 안되어있는것 같아 경험하면서 이해했던것 토대로 간단하게나마 포스팅하고자 한다.

 

이 포스팅은 OAuth 2.0의 4가지 방식중 Authorization code를 통해 토큰(권한)을 부여받는 Authorization code grant 방식 기반으로 설명하고자 한다.

 

 

OAuth 2.0이란?

 

간단히 요약하면 내가 어떠한 서비스를 사용자에게 제공한다고 가정하자.

그렇다면 스스로 애플리케이션 서버를 구축 및 로그인 및 회원가입 서비스를 구현하기위해 사용자로부터 개인정보를 받아 저장하고 관리해야 할 것이다.

 

하지만 OAuth 2.0을 사용한다면 대부분의 로그인, 개인정보 관리 책임을 서드파티 애플리케이션 (Google, Facebook, Kakao 등)에게 위임할 수 있다. (단, 사용자가 기존에 서드파티 서비스에 회원가입이 되어있어야 함) 뿐만아니라 각 서드파티가 가지고 있는 사용자의 리소스를 조회 등을 내 애플리케이션에서 수행할 수 있다.

 

더 추상적으로 생각해보면 사용자가 하나의 A라는 애플리케이션만 가입한다면 기타 다른 다양한 애플리케이션에서 각각 사용자가 권한을 부여 받을 필요 없이 A 애플리케이션으로 부터 부여 받은 권한을 통해 기타 다른 다양한 애플리케이션에서 행사 할 수 있다.

 

예시로는 내가 만든 애플리케이션에서 사용자가 Kakao 로그인을 통해 로그인했다면 사용자가 넘겨준 토큰으로 내 애플리케이션에서 Kakao Resource 서버로부터 해당 사용자의 프로필 정보 등을 조회할 수 있다.

 

 

OAuth 2.0의 요소

 

OAuth 2.0의 요소로는 보통 다음과 같다. 일반화된것은 아니고 상황에 따라 유연하게 변경될 수 있는것 같다.

 

구분	설명
Client	OAuth 2.0을 사용해 서드파티 로그인 기능을 구현할 자사 또는 개인 애플리케이션 서버다.
Recource Owner	서드파티 애플리케이션 (Google, Facebook, Kakao 등)에 이미 개인정보를 저장(회원가입)하고 있으며 Client가 제공하는 서비스를 이용하려는 사용자, 'Resource' 는 개인정보라고 생각하면 된다.
Resource Server	사용자의 개인정보를 가지고있는 애플리케이션 (Google, Facebook, Kakao 등) 서버다.  Client는 Token을 이 서버로 넘겨 개인정보를 응답 받을 수 있다.
Authorization Server	권한을 부여(인증에 사용할 아이템을 제공주는)해주는 서버다. 사용자는 이 서버로 ID, PW를 넘겨 Authorization Code를 발급 받을 수 있다. Client는 이 서버로 Authorization Code을 넘겨 Token을 발급 받을 수 있다.

 

시퀀스 다이어그램으로 설명하면 구조는 다음과 같다. (PAYCO에서 명확하게 잘 표현해주고 있어 인용하고자한다.)

 

출처: PAYCO 개발자 센터

 

시퀀스 다이어그램에는 refresh token이 없지만 보통 Authorization Server로 부터 access token(비교적 짧은 만료기간을 가짐) 과 refresh token(비교적 긴 만료기간을 가짐)을 함께 부여 받는다.

access token은 보안상 만료기간이 짧기 때문에 얼마 지나지 않아 만료되면 사용자는 로그인을 다시 시도해야한다. 그러나 refresh token이 있다면 access token이 만료될 때 refresh token을 통해 access token을 재발급 받아 재 로그인 할 필요없게끔 한다.

 

 

마치며

 

JWT와 OAuth 2.0의 명확한 차이는 뭘까?

JWT와 OAuth 2.0 둘 다 인증 관점에서 비교하여 생각할 수 있겠지만 서로가 추구하는 목적이 다르다.

 

OAuth 2.0는 하나의 플랫폼의 권한(아무 의미없는 무작위 문자열 토큰)으로 다양한 플랫폼에서 권한을 행사할 수 있게 해줌으로써 리소스 접근이 가능하게 하는데 목적을 두고있다. 즉 권한 부여 프레임워크이다.

 

JWT는 Cookie, Session을 대신하여 의미있는 문자열 토큰으로써 권한을 행사할 수 있는 토큰의 한 형식이다. (로그인 세션이나 주고받는 값이 유효한지 검증할 때 주로 쓰인다.)

 

OAuth 2.0 에서 의미없는 정보를 가지는 토큰이 의미있는 정보를 가져야한다면 두 기술을 혼합하여 access token 을 JWT 형식으로 구현할 수도 있다.