Oauth의 등장 배경 및 개념 이해해보기
이번 아티클에서는 Oauth의 개념을 알아보고 어떻게 인증 플로우를 구성할 수 있는지 알아보겠습니다.
Oauth의 등장 배경
Oauth에 대해 알아보기에 앞서, 왜 등장했는지부터 이해해봅시다. Oauth가 등장하기 이전에는 인증방식에 대한 표준이 존재하지 않았습니다. 따라서 각 서비스마다 자체적으로 아이디 비밀번호를 관리하는 형태였습니다.
이런 상황에서 서비스 간에 정보를 공유해야 하는 상황이 생겼다고 가정해봅시다. 예를 들어 사용자의 일정 관리를 도와주는 A라는 서비스가 있는데, A 서비스에서는 보다 수월한 일정 관리를 위해서 사용자의 '구글 캘린더' 정보를 필요로 합니다.
이 때, 어떻게 사용자의 구글 캘린더 정보를 받아올 수 있을까요? A라는 서비스에서는 해당 유저에 대한 구글 계정 정보를 모르는데 말입니다.
이 문제를 해결하기 위한 가장 간단한 방법은 사용자가 구글 계정을 A 서비스에 제공하는 것입니다. 하지만 다음과 같은 문제점들이 생깁니다.
- 사용자 개인정보 유출
- 계정이 구글 캘린더 이외의 기능에 접근하는데에도 사용될 수 있음
- 캘린더를 제공하는 구글(third-party) 입장에서도 사용자 계정 관리가 어려워짐
Oauth는 개방형 표준 프로토콜로서, 이러한 문제점들을 해결하기 위해 등장했습니다. Oauth를 사용하면 앞서 설명드린 예시에서처럼 구글 캘린더를 사용하는 등의 어플리케이션 통합이 간단하지게 됩니다. 즉, 위 방식과 같이 구글 아이디, 비밀번호를 서비스에게 직접적으로 제공할 필요가 없어지게 된 것입니다.
이제부터는 도대체 Oauth는 어떤 개념을 사용하기에 이러한 문제점들을 해결했는지 알아보도록 하겠습니다.
Oauth 용어 정리
Oauth를 이해하려면 Oauth 표준 문서에서 공식적으로 정의한 역할(Roles)들에 대해 짚고 넘어갈 필요가 있습니다. 총 4가지가 존재하는데, 간략하게 살펴보도록 하겠습니다.
- resource owner
리소스 소유자를 의미합니다. 웹 어플리케이션에서는 사용자가 resource owner라고 생각하셔도 무방합니다.
- client
resource owner로부터 인가를 받고, 자원에 접근하는 주체입니다. 웹 어플리케이션에서는 '웹 서비스'가 client라 생각하셔도 무방합니다.
- authorization server
리소스에 접근할 수 있는 access token을 client에게 발급하는 역할을 합니다.
- resource server
실제 리소스를 갖고 있는 서버입니다. access token을 통해 resource server에 접근할 수 있습니다.
지금은 용어가 이해되지 않아도 괜찮습니다. 다만 이렇게 역할을 분리한 것이 Oauth의 핵심 개념이다!는 알고 넘어가주셨으면 합니다. OAuth의 핵심 컨셉이 '클라이언트와 리소스 소유자를 분리하는 것'이기 때문입니다.
Oauth flow
이제 Oauth flow에 대해 알아보도록 하겠습니다. 앞서서 '사용자의 구글 캘린더를 사용해 일정관리를 도와주는 A 서비스' 예시를 들었던 적이 있었습니다. 해당 예시를 통해 Oauth flow까지 설명하도록 하겠습니다.
마찬가지로 A 서비스가 사용자의 구글 캘린더가 필요한 상황이라고 해봅시다. Oauth를 사용하는 경우 다음과 같은 플로우를 가지게 됩니다.
순서대로 살펴보면
- 일정관리 서비스가 사용자에게 캘린더를 써도 되냐고 묻고
- 좋다는 응답을 받으면
- 구글 인가 서버에게 access token을 달라고 요청합니다.
- 캘린더에 접근할 수 있는 access token을 받고난 뒤
- access token을 통해 유저의 캘린더를 요청하면
- 구글 캘린더 서버는 캘린더를 응답합니다.
이 내용이 Oauth 표준 문서에서 정의하고 있는 핵심 Oauth 플로우입니다. 다만 위 플로우에서 2번에 해당하는 부분(resource owner가 client에게 권한을 부여해주는 부분)이 어떻게 달라지냐에 따라 Oauth 플로우가 4종류로 나뉘는데, 각각에 대해서 알아보도록 하겠습니다.
1. Authorization Code Grant
첫번째로 소개할 방식은 Authorization Code Grant 방식이고, 가장 기본이 되는 방식입니다. 이는 resource owner가 client에게 권한을 부여해줄 때 Authorization Code를 전달해주는 방식을 의미합니다.
이 방식은 Authorization Code를 리다이렉션 URI 경로에 포함시켜서 반환해줍니다. access token, refresh token이 모두 사용 가능한 방식입니다. 대부분의 경우 '웹 어플리케이션에서 OAuth를 사용한다!' 라고 하면 Authorization Code Grant 방식을 사용한다고 생각하시면 됩니다.
사용자의 권한을 안전하게 관리하고 보안을 강화하는데 가장 적합한 Oauth 플로우입니다. access token, refresh token 사용이 모두 가능합니다.
2. Implicit Grant
두번째로 소개할 방식은 Implicit Grant 방식입니다. 자격증명을 따로 브라우저 등에서 관리하기 힘든 경우 사용할 수 있는 방식입니다. (Javascript등의 스크립트 언어를 사용한 브라우저 등)
앞선 Authorization Code Grant 방식에서 Authorization Code를 발급받는 과정을 제거했다고 보시면 될 것 같은데요, 이를 통해 인증 과정이 짧아져 요청 / 응답 효율성이 높아진다는 장점이 있습니다. 하지만 Access Token을 발급할 때 URI로 전달된다는 단점은 존재합니다. 또한 이 방식의 경우 보안 상의 이유로 refresh token을 지원하지 않습니다.
3. Resource Owner Password Credentials Grant
세번째로 소개할 방식은 Resource Owner Password Credentials Grant 방식입니다. 이 방식은 정말 간단한게, 단순히 아이디와 비밀번호만 전달하는 방식입니다.
Oauth는 client와 Resource owner가 충분한 신뢰 관계가 보장되어 있을 때에만 이 방식을 사용하라고 권장하고 있습니다. 예를 들어서 Resource owner와 client가 같은 경우가 있을 수 있겠고, 혹은 client가 운영체제인 경우가 있을 수 있겠습니다. access token과 refresh token을 모두 지원하는 방식입니다.
4. Client Credentials Grant
4가지 Oauth 플로우 중 가장 간단한 방식으로 클라이언트가 인증을 하고 권한을 받는 방식입니다.
이 방식은 사용자의 개인정보가 필요하지 않은 경우 유용하게 사용될 수 있습니다. 주로 서버 간의 통신 등에 사용됩니다. 그리고 refresh token을 지원하지 않는 방식입니다.
마치며
Oauth의 등장 배경부터 개념, 그리고 Oauth flow 4가지에 대해 알아보았습니다. 대부분의 경우 Authorization Code Grant 방식을 사용하고, 어플리케이션이 특수한 경우라면 기타 Oauth 플로우를 고려하면 될 것 같습니다.
감사합니다.