OAuth 2.1; OAuth 2.0과 무엇이 다를까
인증과 인가, OAuth 개념 바로잡기
개요
개발을 하다보면 인증 이야기만 나오면 꼭 함께 등장하는 단어가 있다.
바로 OAuth.
문제는 OAuth를 인증 프로토콜이라고 적어놓은 글들이 많다. 나도 그렇게 알고 있었던 적이 있었다. 아마 Authorize가 번역기에 의해 인증이라는 단어로 해석된 것도 한 몫하는 것 같기도 하다. 하지만 OAuth는 인증 프로토콜이 아니다.
그래서 이번 프로젝트에 인증을 넣기 전에, OAuth의 개념부터 최신 표준인 OAuth 2.1까지 한 번 정리해보려고 한다.
🔐 인증(Authentication)과 인가(Authorization)
먼저 인증과 인가에 대해 알아보자.
- 인증은 요청을 보낸 사람이 누구인지 신원을 확인하는 것이다.
- 인가는 요청을 보낸 사람이 어떤 자원에 접근할 수 있는지 권한을 부여하는 것이다.
비유하자면 비행기를 타기 전 여권을 통해 신원을 확인하는 단계가 인증이다. 그리고 비행기 티켓은 비행기를 탈 수 있는 권한(인가)을 증명한다.
여기서 알아두어야 하는 점은 인가를 얻었다고 인증을 한 것이 아니라는 점이다. 비행기 티켓이 있다고 해도 여권 없이 비행기를 타지 못하는 것처럼 말이다.
🤔 OAuth는 인증 프레임워크다?
위키피디아에 따르면, OAuth의 정의는 다음과 같다.
OAuth (Wikipedia) OAuth (short for open authorization) is an open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism is used by companies such as Amazon, Google, Meta Platforms, Microsoft, and Twitter to permit users to share information about their accounts with third-party applications or websites.
정리하자면 제 3자 앱이 사용자 대신 특정 자원에 제한적으로 접근(access)할 수 있도록 권한을 부여해주는 인가(authoriztion) 프레임워크다. 즉 OAuth는 내 비밀번호를 누구에게도 넘기지 않으면서, 내 계정의 일부 기능을 사용할 수 있도록 허락해주는 구조를 제공하는 것이다.
💬 너의 구글 캘린더에 등록한 일정을 읽을 권한이 필요해!
예시를 드는 편이 좀 더 이해하기가 수월할 것이다.
PigDaily라는 일정 관리 앱을 만든다고 해보자. PigDaily에 자체 캘린더가 있지만, 사용자 입장에서는 구글 캘린더에 있는 일정도 같이 보여주면 좋겠다고 생각할 것이다. 가장 단순하게 떠올릴 수 있는 방법은 이거다:
우리가 사용자의 구글 아이디와 비밀번호를 받아서 대신 로그인하면 되지 않을까?
하지만 이건 보안적으로 정말 위험한 방식이다. 사용자의 비밀번호만 있으면 PigDaily는 구글 캘린더뿐 아니라 사용자의 Google 계정 전체에 접근할 수 있는 것이다. 단지 일정을 읽고 싶은 것 뿐인데, 너무 많은 권한을 가져가게 되는 셈이다.
그래서 OAuth가 등장했다.
OAuth를 이용하면 PigDaily는 이렇게 동작하게 된다:
- 사용자가 PigDaily에서 “구글 캘린더 연동”을 누르면
- PigDaily는 사용자를 구글 로그인 페이지로 리다이렉트한다.
- 사용자는 구글에 직접 로그인한다.
- 로그인 성공 시, 구글은 “PigDaily가 당신의 캘린더 읽기 권한을 가져가도 될까요?”라고 묻는다.
- 사용자가 승인하면, PigDaily는 사용자의 구글 비밀번호 없이도, 구글 캘린더에 접근할 수 있는 제한된 권한을 얻게 된다.
여기서 핵심은 PigDaily는 구글 캘린더에 접근할 권한(인가)만 부여 받았다는 것이다. 즉 PigDaily는 이 사용자가 누구인지를 증명하는 인증 정보를 받지 않는다.
그래서 OAuth는 인증 프로토콜이 아니다. OAuth만으로는 이 사용자가 누구인지 판별할 수 없다.
만약 로그인 기능처럼 이 사용자가 누구인지 식별해야 한다면, OAuth를 기반으로 인증 기능을 추가한 OIDC(OpenID Connect) 같은 상위 프로토콜이 필요하다.
OAuth 2.1
OAuth는 1.0 → 1.0a → 2.0 → 그리고 지금의 2.1까지 발전해왔다.
특히 OAuth 2.0 이후에는 많은 기업과 개발자들이 여러 보안 문제에 부딪혔고, 그 과정에서 best practice들이 쌓이게 되었다.
OAuth 2.1은 이러한 best practice들을 모아 정리한 표준이다. 즉 새로운 프로토콜이 아니라 기존 OAuth 2.0을 개선하여 재정리한 문서에 가깝다.
역사와 변화 흐름은 NHN Forward 22 영상에서 아주 이해하기 좋게 설명해준다.