OAuth 2.0

OAuth 등장 배경

요즘 개발되는 서비스는 독립적으로 혼자만의 기능을 쌓아올리진 않습니다.

타 서비스의 기능을 본인의 서비스에 접목시켜서 사용자가 사용하기 편하며, 시너지를 발생시켜 더 놀라운 기능을 제공해주죠.

하지만, 이 때 타사의 서비스에서 소유자만 접근 가능 한 리소스를 접근하는 것이 문제가 됩니다.

별도의 인증과 인가 과정이 필요하기 때문이죠.
OAuth를 적용하기 전 어떠한 방식으로 이를 구현하는 지 한번 보겠습니다.

 

OAuth 적용 이전

나만의 캘린더는 유저만 접근 가능한 리소스인 구글 캘린더 정보에 접근해야 합니다.
이 때 캘린더에 접근하기 위해서, 다음과 같은 흐름을 거칩니다.

1. 유저에게 구글 ID와 PW를 제공 받고,
2. 이를 통해서 나만의 캘린더는 구글에 로그인을 합니다.
3. 구글에선 이 로그인이 유효한걸 확인하고, 사용자의 캘린더 정보를 나만의 캘린더에게 돌려 줍니다.
4. 나만의 캘린더는 받은 캘린더 정보를 가공하여 유저에게 서비스를 제공합니다.

위와 같은 흐름에서는 다양한 문제가 발생할 수 있습니다.

1. 유저 입장에서는 인증정보를 나만의 캘린더에게 넘기는 것이기에, 나만의 캘린더가 이를 따로 빼돌리거나, 해당 인증정보로 유저의 다른 리소스에도 접근할 수 있죠.
2. 나만의 캘린더를 운영하는 입장에서도 사용자의 정보를 저장하는 것은 부담입니다. 유저의 구글 ID와 PW 같이 중요도가 높은 인증정보를 관리하다가 유출된다면? 바로 서비스를 내려야 할 것입니다.
3. 구글 입장에서도 이는 달가운 일이 아닙니다.
   아무리 구글이 보안 수준을 높이는 방식으로 서비스를 구성하더라도, 사용자의 인증 정보 자체가 노출되면, 구축한 보안이 무용해집니다.

그러면 이러한 문제가 왜 생기는 걸까요?
바로 나만의 캘린더에서 유저의 ID, PW를 사용하기 때문에 일어난 문제입니다.

자 처음으로 돌아가서,

나만의 캘린더는 왜 구글 ID, PW를 사용했을까요?

유저의 캘린더에 접근 권한을 부여받기 위해섭니다.
즉, 인가과정 때문이죠.

인가가 실행되기 위해선 선행되는 과정이 있습니다. 무엇일까요?
바로 인증입니다.

그래서, 나만의 캘린더는 인가를 위한 권한을 받기 위해서, 인증과정을 수행했던 것입니다.

그러면, 이렇게 생각해보면 어떨까요?

인증은 유저가 직접
권한은 서비스에게 부여

 

인증의 책임은 유저에게, 리소스에 접근하는 책임은 서비스에게 부여하는 것이죠.

이러한 아이디어에서 시작된 게 OAuth입니다.

OAuth 적용 이후

유저는 구글에 직접 인증을 합니다. 중요한 건 이 인증과정에 참여하는 주체는 오로지 유저와 구글 뿐이라는 사실입니다.

나만의 캘린더는 이 과정의 어디서도 관여하지 않습니다.

인증이 유효한다면, 구글은 나만의 캘린더에게 권한을 부여합니다.
나만의 캘린더는 이 권한으로 유저의 리소스에 접근할 수 있죠.

이 때 이 권한을 부여하는 과정에서 유저는 배제되어 있습니다.
권한을 전달하고, 이를 사용하는 과정을 최소화 함으로써 탈취당할 위험을 줄인거죠.

여기까지 보시면 알 수 있는 것은

OAuth는 인가를 위해서 설계된 기술이라는 것입니다.

이것이 OAuth의 추상적인 흐름입니다. 이제 이 과정을 어떻게 구체화 했는지 살펴보겠습니다.

 

OAuth Role

• 유저 - Resource Owner
  인증을 수행하는 주체이면서, 실질적으로 리소스에 대한 소유권을 가진
  주체입니다.
  클라이언트에게 리소스에 대한 권한을 위임하죠.
• 나만의 캘린더 - Clinet(Third-party application)
  권한을 위임 받는 주체입니다. 리소스에 소유권을 지니진 않았지만, 위임 받은 권한으로 리소스에 접근합니다.
• 구글
  • Authoriziation Server
    인증의 유효성을 검증하고, 권한을 Clinet에게 부여하는 주체입니다.
  • Resource Server
    인가 과정을 수행하고, 실질적으로 리소스를 Clinet에게 제공하는 주체입니다.