OAuth란?
OAuth란 Open Authorization의 줄임말으로, 정보의 접근 권한을 부여할 수 있는 개방형 표준이다.
사용자가 웹사이트나 애플리케이션에게 비밀번호를 제공하지 않으면서 다른 웹사이트에 있는 자신의 정보에 대한 권한을 부여하는 수단으로 사용된다.
OAuth는 2007년 등장했으며, 2010년에 OAuth 1.0 프로토콜이 표준으로 발표되었고, 2012년에는 OAuth 1.0의 보안 취약점을 개선한 OAuth 2.0 프로토콜이 발표되었다.
위와 같이 네이버, 카카오, 페이스북 등 다른 웹사이트 계정을 이용해 소셜 로그인을 한 번쯤은 해보았을 텐데, OAuth를 통해 소셜 로그인을 할 수 있다.
OAuth가 왜 필요한가?
쉬운 이해를 위해, 우리가 구글 계정을 이용해 Zoom에 가입한다고 해보자.
Zoom 친구 추가와 회의 일정 동기화 기능을 제공하기 위해, Zoom은 연락처와 캘린더 개인 정보를 구글로부터 받아온다.
Zoom은 구글이라는 외부 웹사이트에 있는 사용자의 정보를 얻어와야 하기 때문에, 사용자의 구글 계정 정보를 받아 구글로부터 사용자의 정보를 얻어온 뒤, 그것을 바탕으로 서비스를 해준다.
조금만 보더라도 이러한 방식에 어떤 문제가 있는지 알 수 있을 것인데, Zoom에 구글 계정을 그대로 넘기기 때문에, Zoom이 너무나 많은 권한을 갖게 된다는 것이다.
예를 들어, 내가 구글에 있는 나의 개인정보 중에서 연락처와 캘린더 정보만을 사용하기를 원했을 수 있겠지만, Zoom은 그밖의 다른 권한도 모두 갖게 된다.
또한, 만약 Zoom이 악의적인 의도를 갖고 나의 계정을 탈취할 수도 있다.
따라서 비밀번호와 같은 계정 정보를 제공하지 않고도, access token을 이용해 제한된 개인정보만을 접근할 수 있도록 권한을 부여하는 OAuth 방법을 사용하게 되었다.
OAuth의 주체
OAuth에서는 4개의 주체가 서로 메시지를 주고받으며 접근 권한을 부여하고 서비스를 제공한다.
4개의 주체는 다음과 같다.
- Resource Owner
- Client
- Authorization Server
- Resource Owner
하나씩 알아보자.
Resource Owner (사용자)
Resource Owner는 Zoom 서비스를 사용하려는 사용자이다.
여기서 resource라는 말은 사용자의 개인정보를 나타내는 것으로, 예를 들어 아래 사진에서는 사용자(resource owner)에게 gmail의 이메일, 연락처, 캘린더(resource)에 대한 권한을 요구하고 있다.
Client (줌)
Client란, resource를 사용해 서비스를 하려는 어플리케이션/웹사이트이다.
구글 계정을 이용해 Zoom을 이용한다고 하면 Zoom이 client와 대응된다.
Authorization Server (구글)
Authorization Server는 resource로의 authorization을 맡는 서버로, 위 예시에서는 accounts.google.com이 authorization server가 될 것이다.
Resource Server (구글)
사용자의 개인 정보인 resource를 가지고 있는 서버이다. (google)
OAuth 과정
이 글에서는 OAuth 2.0의 여러 방식 중 많이 사용되는 Authorization Code Grand(권한 부여 승인 코드 방식)에 대해 다룬다.
OAuth 2.0의 권한 부여 방식에는 Authorization Code Grand(권한 부여 승인 코드 방식) 이외에도 Implicit Grant(암묵적 승인 방식), Resource Owner Password Credentails Grant(자원 소유자 자격증명 승인 방식), Client Credentials Grant(클라이언트 자격증명 승인 방식)이 존재한다.
다른 OAuth 2.0의 권한 부여 방식이 궁금하다면 https://velog.io/@flasharrow/OAuth2.0-이해를 참고하자.
위 그림은 OAuth의 과정을 간략하게 설명한 것으로, 크게 아래와 같은 과정으로 이뤄진다.
- 사용자(Resource Owner)의 승인: 줌(Client)이
authorization code를 발급받음 (1,2) - 구글(Authorization Server)의 승인: 줌(Client)이
access token을 발급받음 (3,4) - 줌(Client)의 서비스 제공: 줌(Client)은
access token을 이용해 구글(Resource Server)로부터 사용자의 정보를 가져와 서비스함 (5,6)
아래에서는 위 과정들을 하나하나씩 풀어 설명해 보겠다.
OAuth 등록
위 OAuth 과정을 나타낸 그림에는 그려져 있지 않았지만, 줌(client)이 resource를 사용하기 위해서는 사전에 구글(authorization server)에 등록(register)해야 한다.
등록을 하면 줌(client)과 구글(authorization server) 모두가 다음 정보를 가지게 된다.
Client IDClient Secret(비밀번호와 유사)Authorized redirect URIs
이것은 아래의 모든 과정을 거치기 이전에 이미 이뤄져 있어야 한다.
사용자(Resource Owner)의 서비스 요청
사용자(resource owner)가 줌(client)으로부터 로그인 페이지를 요청하면, 줌(client)은 로그인 페이지를 제공한다.
사용자(Resource Owner)의 승인 (1, 2)
사용자(resource owner)는 client ID와 redirect URI와 함께 구글(authrization server)에 로그인 페이지를 요청한다.
즉, 아래와 같은 URI 형식으로 로그인 페이지를 요청한다. (예시일 뿐이며, 완전히 같지 않을 수 있다)
https://accounts.google.com/
?client_id=1234
&scope=C,D
&redirect_uri=https://redirect여기서, client ID와 redirect URI는 이미 등록(register)과정에서부터 줌(client)과 구글(authorization server)가 서로 알고 있는 것이다.
구글(authorization server)은 자신이 알고 있는 client ID, redirect URI 정보와 사용자(resource owner)가 제공한 client ID, redirect URI 정보가 서로 일치하는지 확인한 후, 만약 일치한다면 로그인 페이지로 이동한다.
사용자(resource owner)는 로그인 페이지를 통해 아이디와 비밀번호를 입력하여 인증한 뒤, 아래와 같이 어떠한 범위(scope)의 개인정보를 줌(client)이 사용해도 될지 확인받는다.
만약 사용자(resource owner)가 최종으로 개인정보 권한을 위임하면, 구글(authorization server)은 authorization code를 사용자에게 발급하고, 이는 줌(client)에게 전달된다.
이로써, 사용자(resource owner)로부터 일정 범위의 개인정보를 사용해도 좋다는 승인을 얻었다.
Authorization Server의 승인 (3, 4)
이제 구글(authorization server)로부터 개인정보를 사용해도 좋다는 승인을 얻을 차례이다.
줌(client)은 사용자(resource owner)로부터 전달받은 authorization code를 이용해 구글(authorization server)에 access token을 요청한다.
구글(authorization server)은 사용자(resource owner)가 전달한 정보와 줌(client)가 전달한 정보가 서로 일치하는지 확인한 후, 만약 일치한다면 줌(client)에게 access token을 발급해준다.
access token을 발급받은 줌(client)은 사용자(resource owner)에게 로그인이 성공했음을 알린다.
이제 줌(client)은 access token을 이용해 구글(resource server)로부터 일정 범위의 개인정보에 접근할 수 있다.
Client의 서비스 제공 (5, 6)
이제 줌(client)는 access token만을 가지고 사용자의 별도 추가 승인 없이 일정 범위의 개인 정보에 접근할 수 있는 권한을 갖게 되었다.
이제 사용자(resource owner)가 캘린더 회의 일정 동기화와 같은 기능을 요청한다면, 줌(client)는 구글(resource server) 안에 저장된 개인정보를 이용해 서비스를 해줄 수 있는 것이다.
Refresh Token
Access token은 만료 기간이 있다.
Access token이 만료될 때마다 항상 위와 같은 과정을 거치기에는 번거롭기 때문에 일반적으로 resource server에서는 access token을 발급할 때 refresh token도 함께 발급한다.
Access token이 만료되면, client는 보관 중이던 refresh token을 이용해 새로운 access token을 발급받을 수 있다.
OAuth 장점과 단점
OAuth는 라이브러리도 잘 만들어져 있는 만큼 편리하게 auth에 사용할 수 있다는 장점이 있지만, 아래와 같은 취약점들이 존재한다고 하니 참고하자.
OAuth 2.0 대표 취약점과 보안 고려 사항 알아보기
References
IETF - The OAuth 2.0 Authorization Framework
