[OAuth2.0] OAuth2.0을 사용하는 이유

---

이번 글에서는 전 세계 표준 권한 위임, 인가 오픈 프로토콜인 OAuth2.0에 대해 알아보도록 하겠습니다.

0. OAuth2.0이란?

서로 다른 두 집단이 정보와 리소스를 안전하고 신뢰할 수 있는 방법으로 공유할 수 있게 해주는 프로토콜입니다.

제가 글을 쓰고 있는 플랫폼인 Velog도 OAuth2.0을 사용해 아래와 같이 서비스를 제공하고 있습니다. '~로 로그인'은 OAuth2.0을 활용하는 대표적인 서비스입니다.

1. 인증(Authentication)과 인가(Authorization)

OAuth2.0을 이해하기 위해서는 인증(Authentication)과 인가(Authorization)에 대한 이해가 필요합니다.

✔ 인증

인증은 누군가가 그들이 말하는 그 사람이 맞는지 실제로 확인하는 절차입니다. 사용자의 '아이디'와 '비밀번호'를 통해 로그인하는 경우 등을 인증이라고 볼 수 있습니다.

✔ 인가

인가는 일단 인증이 됐다면 당신이 하고 하는 어떤 일을 할 수 있는 권한이 있는지를 판단하는 절차입니다. 아이디와 비밀번호로 로그인후 해당 사용자가 실제 요청한 서비스에대한 '접근 권한'이 있는지를 확인하는 경우 등을 인가라고 볼 수 있습니다.

2. OAuth2.0 사용

OAuth2.0은 일반적으로 아래 두 가지의 용도로 사용됩니다.

✔ 연합된 신원(federated identity)

사용자가 자신의 다른 계정으로 애플리케이션에 로그인할 수 있게 해줍니다. 예를 들면 Google 계정으로 Velog와 Github에 로그인하는 경우, 해당 사용자는 단지 Google 계정 하나만 관리하면 됩니다. 이런 의미에서, 여러 사이트들이 연합해 하나의 사용자 신원을 사용한다고 말할 수 있습니다.

✔ 권한 위임(delegated authority)

어떤 서비스가 사용자를 대신해서 다른 서비스의 리소스에 접근할 수 있게 해줍니다. 예를 들면 LinkedIn에서 구글 사용자의 연락처 리스트를 보고 그 연락처에 있는 사람들을 링크드인 친구로 등록할 것을 추천하는 경우입니다. 즉, 사용자의 구글 연락처 리스트에 접근할 수 있는 권한이 링크드인에 위임된 것입니다.

사실 위의 두 용도는 엄밀히 말하자면 같은 경우입니다. 두 가지 경우 모두 보호된 리소스에 해당 리소스 소유자를 대신해서 접근하는 것 입니다.

3. OAuth2.0이 없다면?

이제 OAuth2.0을 알아보기 전에, OAuth2.0이 없던 시절에는 집단간 리소스 공유를 어떻게 해결하였는지 알아보겠습니다.

먼저 사용자가 Velog에 새로 가입했으며, Velog는 사용자의 구글 연락처 목록을 보고 그 중에서 친구로 등록할 사람을 추천하려한다고 가정했을때의 과정은 아래와 같습니다.

1. 사용자가 Velog에게 친구 추천을 요청한다.
2. Velog는 사용자에게 구글 로그인을 위한 ID/PW를 요구한다.
3. 사용자는 Velog에게 ID/PW를 전달한다.
4. Velog는 전달받은 ID/PW를 이용해 구글에 로그인해서 사용자의 연락처 정보를 요청한다.
5. 구글은 Velog에게 사용자의 연락처 목록을 전달한다.
6. Velog는 사용자의 연락처 목록을 이용해 사용자에게 친구를 추천한다.

위 방법의 문제점은 무엇일까?

1. 사용자는 Velog에게 계정 정보를 전달함으로써 Velog가 사용자 계정으로 무엇이든 할 수 있는 능력을 제공했다.
2. Velog은 비밀번호를 안전하지 않은 방법으로 저장할 수 있다.
3. 사용자의 비밀번호가 인터넷을 통해 탈취될 가능성이 크다.
4. Velog가 해킹된다면 사용자는 구글 비밀번호를 변경해야 한다.
5. Velog의 구글 접근권한을 취소시킬 수 있는 방법이 없다.

4. OAuth2.0를 사용한다면?

기존의 방법은 여러가지 문제점이 있는 것을 확인했습니다. 그렇다면 OAuth2.0은 어떻게 위의 문제점을 해결했는지 알아보겠습니다.

만약 Velog가 OAuth2.0을 사용한다면 전체 흐름은 아래와 같이 달라집니다.

1. 사용자가 Velog에게 친구 추천을 요청한다.
2. Velog는 사용자에게 구글 연락처 접근을 위한 권한을 달라고 요청한다.
3. 사용자는 Google에 로그인 후 Google에게 Velog한테 내 연락처 접근을 위한 권한을 주라고 요청한다.
4. Velog는 Google에게서 사용자 연락처 접근을 허용하는 권한을 받는다.
5. Velog는 전달받은 권한을 사용해 Google에게 사용자 연락처 정보를 요청한다.
6. Google은 Velog의 권한을 확인 후 사용자의 연락처 정보를 전달한다.
7. Velog는 전달받은 연락처 정보를 활용해 사용자에게 친구를 추천한다.

위 방법의 왜 더 좋을까?

1. 사용자는 Velog에게 ID/PW를 전달하지 않는다. 따라서 ID/PW가 탈취당할 일도 없다.
2. Velog가 해킹당하더라도 사용자는 Google ID/PW를 바꿀 필요가 없다.
3. 사용자가 직접 Velog의 접근권한을 취소시킬 수 있다.

5. 결론

OAuth2.0을 사용하면?
-> 여러 서비스 제공자의 API를 신뢰 할 수 있는 방법으로 사용할 수 있다.

---

참고자료

OAuth 2.0 마스터:OAuth 2.0 애플리케이션 개발을 위한 모든 것

파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음

---