우아한 테크코스에서 테코톡이라는 세미나가 있습니다.
테코톡에서는 크루들이 하나의 개념 또는 기술을 정하고, 이를 10분정도 발표하여 지식을 공유하는 일종의 행사입니다.
저는 이번에 OAuth 2.0이라는 기술로 테코톡을 진행했습니다.
일상생활에서 많이 접할 수 있는 기술인데, 기존에 아예 알지 못했어서 이번 기회에 제대로 배워보고자 테코톡 주제로 골랐습니다.
테코톡에서 시간 관계상 다루지 못한 내용도 많아서, 블로그에 포스팅 해보려고 합니다.
인증과 인가
OAuth 2.0에 대해 알고자 하면, 인증과 인가에 대해서 알고 있어야 합니다.
만약 인증과 인가에 대해서 잘 모르신다 하시면, 아래 추천 영상에 들어가서 학습을 하시는 것을 추천합니다.
추천 영상
OAuth 등장 배경
요즘 개발되는 서비스는 독립적으로 혼자만의 기능을 쌓아올리진 않습니다.
타 서비스의 기능을 본인의 서비스에 접목시켜서 사용자가 사용하기 편하며, 시너지를 발생시켜 더 놀라운 기능을 제공해주죠.
하지만, 이 때 타사의 서비스에서 소유자만 접근 가능 한 리소스를 접근하는 것이 문제가 됩니다.
별도의 인증과 인가 과정이 필요하기 때문이죠.
OAuth를 적용하기 전 어떠한 방식으로 이를 구현하는 지 한번 보겠습니다.
유저의 구글 캘린더에 접근하여, 일정을 통합해서 관리해주는 우테코 캘린더라는 서비스를 만든다고 가정하고, 이야기를 하겠습니다.
OAuth 적용 이전
우테코 캘린더는 유저만 접근 가능한 리소스인 구글 캘린더 정보에 접근해야 합니다.
이 때 캘린더에 접근하기 위해서, 다음과 같은 흐름을 거칩니다.
- 유저에게 구글 ID와 PW를 제공 받고,
- 이를 통해서 우테코 캘린더는 구글에 로그인을 합니다.
- 구글에선 이 로그인이 유효한걸 확인하고, 사용자의 캘린더 정보를 우테코 캘린더에게 돌려 줍니다.
- 우테코 캘린더는 받은 캘린더 정보를 가공하여 유저에게 서비스를 제공합니다.
위와 같은 흐름에서는 다양한 문제가 발생할 수 있습니다.
-
유저 입장에서는 우테코 캘린더를 신뢰할 수 없습니다.
유저 입장에서는 인증정보를 우테코 캘린더에게 넘기는 것이기에, 우테코 캘린더가 이를 따로 빼돌리거나, 해당 인증정보로 유저의 다른 리소스에도 접근할 수 있죠. -
우테코 캘린더 입장에서도 이는 큰 부담입니다.
유저의 구글 ID와 PW 같이 중요도가 높은 인증정보를 관리하다가 유출된다면? 바로 서비스를 내려야 할 것입니다. -
구글 입장에서도 이는 달가운 일이 아닙니다.
아무리 구글이 보안 수준을 높이는 방식으로 서비스를 구성하더라도, 사용자의 인증 정보 자체가 노출되면, 구축한 보안이 너무 무용해지죠.
그러면 이러한 문제가 왜 생기는 걸까요?
바로 우테코 캘린더에서 유저의 ID, PW를 사용하기 때문에 일어난 문제입니다.
자 처음으로 돌아가서,
우테코 캘린더는 왜 구글 ID, PW를 사용했을까요?
유저의 캘린더에 접근 권한을 부여받기 위해섭니다.
즉, 인가과정 때문이죠.
인가가 실행되기 위해선 선행되는 과정이 있습니다. 무엇일까요?
바로 인증입니다.
그래서, 우테코 캘린더는 인가를 위한 권한을 받기 위해서, 인증과정을 수행했던 것입니다.
그러면, 이렇게 생각해보면 어떨까요?
인증은 유저가 직접
권한은 서비스에게 부여
인증의 책임은 유저에게, 리소스에 접근하는 책임은 서비스에게 부여하는 것이죠.
이러한 아이디어에서 시작된 게 OAuth입니다.
OAuth 적용 이후
유저는 구글에 직접 인증을 합니다. 중요한 건 이 인증과정에 참여하는 주체는 오로지 유저와 구글 뿐이라는 사실입니다.
우테코 캘린더는 이 과정의 어디서도 관여하지 않습니다.
인증이 유효한다면, 구글은 우테코 캘린더에게 권한을 부여합니다.
우테코 캘린더는 이 권한으로 유저의 리소스에 접근할 수 있죠.
이 때 이 권한을 부여하는 과정에서 유저는 배제되어 있습니다.
권한을 전달하고, 이를 사용하는 과정을 최소화 함으로써 탈취당할 위험을 줄인거죠.
여기까지 보시면 알 수 있는 것은
OAuth는 인가를 위해서 설계된 기술이라는 것입니다.
이것이 OAuth의 추상적인 흐름입니다. 이제 이 과정을 어떻게 구체화 했는지 살펴보죠.
OAuth Flow
OAuth를 공식적으로 정의한 문서인 RFC-6749에서는 총 4가지 흐름을 정의했습니다.
- Authorization Code Flow
- Implicit Flow
- Resource Owner Password Credentials Flow
- Client Credentials
하지만, 대부분의 OAuth 제공사들이 Authorization Code Flow를 지원하기에 Authoriation Code Flow 기준으로 글을 진행하도로 하겠습니다.
OAuth Role
아까 예를 들었던 우테코 캘린더에서의 각각의 주체를 OAuth에서 부르는 용어가 있습니다. 이를 간단하게 짚고 넘어가보죠.
-
유저 - Resource Owner
인증을 수행하는 주체이면서, 실질적으로 리소스에 대한 소유권을 가진
주체입니다.
클라이언트에게 리소스에 대한 권한을 위임하죠. -
우테코 캘린더 - Clinet(Third-party application)
권한을 위임 받는 주체입니다. 리소스에 소유권을 지니진 않았지만, 위임 받은 권한으로 리소스에 접근합니다. -
구글
- Authoriziation Server
인증의 유효성을 검증하고, 권한을 Clinet에게 부여하는 주체입니다. - Resource Server
인가 과정을 수행하고, 실질적으로 리소스를 Clinet에게 제공하는 주체입니다.
- Authoriziation Server
OAuth Setting
OAuth를 사용하기 위해선 먼저 선행되어야 하는 것이 있습니다.
바로 OAuth 제공사에 OAuth를 사용할 서비스를 등록하는 것이죠.
등록하는 과정에서 개발자가 설정해야 할 것은 크게 두 가지 입니다.
- 권한을 반환받을 RedirectUri
- 권한에 포함시킬 범위(유저 이메일, 성별, 생일 등등)
redirectUri를 설정하는 것은 보안적인 이유입니다. 추후, 흐름 부분에서 부가적으로 설명하도록 하겠습니다.
권한에 포함시킬 범위를 지정함으로써 부여된 권한이 접근할 수 있는 리소스를 한정지을 수 있습니다.
이를 이용해서 무분별하게, Clinet가 리소스에 접근하는 것을 막을 수 있죠.
추가적으로 서비스를 등록했을 때 꼭 알아야 할 것도 있는데요.
- Client를 식별할 ClientId
- 권한을 발급 받을 때, 발급 요청한 주체가 OAuth 제공사에 등록된 Client인지 인증할 때 사용하는 ClinetSecret
이제 구체적인 흐름을 알아볼텐데 이는 다음 포스트에서 다루도록 하겠습니다.
