OAuth2.0 란?

오늘 백엔드 크루 홍실의 OAuth2.0 테코톡이 진행되었다.

해당 테코톡을 바탕으로 OAuth에 대해 정리해보고자 한다.

 

인증과 인가

인증과 인가는 OAuth을 이해하기 위해 필수적인 개념이다.

 

인증(Authentication)

당신은 누구십니까?

• 사용자의 신원을 확인하는 절차이다.
• 신원 확인을 위해 일반적으로 아이디와 비밀번호 등을 사용한다.

 

인가(Authorization)

당신은 이 작업을 수행할 권한이 있습니까?

• 인증된 사용자에 대한 접근 권한을 부여하는 과정이다.
• 이는 사용자가 특정 리소스에 대해 접근하거나 특정 작업을 수행할 수 있는 권한을 부여하는 것을 포함한다.

 

OAuth의 등장배경

사용자의 구글 캘린더 기반으로 일정을 관리해주는 서비스가 있다고 하자.

OAuth가 없다면, 해당 서비스는 어떻게 사용자의 구글 캘린더 정보를 받아올 수 있을까?

 

간단한 방법을 생각해보면

1. 사용자에게 구글 계정 정보를 입력받고
2. 해당 계정으로 구글에 로그인한 후
3. 사용자의 구글 캘린더 정보를 받아오고
4. 이를 가공하여 서비스를 제공할 수 있다.

 

하지만 해당 방법에서는, 해커가 일정 관리 서비스 DB에 접근하면 손쉽게 사용자의 구글 ID & password를 탈취할 수 있다.

아니면 사실 일정 관리 서비스 자체가 해커가 만든 서비스여서, 사용자 계정로 구글 캘린더 정보 조회 뿐만 아니라 다른 서비스까지 마음대로 활용할 수도 있다.

 

사용자 입장에서는 나의 구글 계정 정보를 신뢰할 수 없는 서비스에게 제공한다는 것 자체가 꺼려진다.

일정 관리 서비스 입장에서는, 자신의 DB가 아주 민감한 사용자 정보를 담고있기 때문에 이를 관리하는 것이 큰 부담이다.

구글 입장에서는, 신뢰할 수 없는 제 3자가 자신의 사용자 계정에 접근할 수 있다는 것이 보안적으로 문제가 된다.

 

즉, 이 방법은 너무 보안적으로 취약하다.

 

이러한 문제를 해결하기 위해 각 어플리케이션(구글, 야후 등)은 각자의 계정 인증 서비스를 제공했다. (ex. 구글 - AuthSub, 야후 - BBAuth)

하지만 이는 표준화되지 않아 특정 어플리케이션에 종속되는 경향이 있었다.

 

OAuth는 어플리케이션 별로 제각각인 인증 방식을 표준화한 인증 방식이다.

 

OAuth란 무엇인가?

OAuth(”Open Authorization”)는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로 사용되는, 접근 위임을 위한 개방형 표준이다.

 

즉, OAuth는 사용자가 자신의 계정 정보를 공유하지 않고, 다른 서비스에 대한 접근 권한을 안전하게 제공하는 개방형 인증 프로토콜이다.

OAuth를 지원하는 서비스는 사용자로부터 인증을 받은 후, 해당 서비스에 대한 접근 권한을 발급하여 제어한다.

 

 

한마디로 정리하면

인증은 사용자가 수행하고

인가는 서비스가 받는다.

 

OAuth1.0 → OAuth2.0

OAuth1.0은 OAuth의 초기버전으로, Consumer Key와 Consumer Secret을 사용하여 서명된 요청을 통해 인증을 구현했다.

이 방법은 보안적으로 강력하지만, 구현과 확장이 어렵다는 단점을 가졌다.

OAuth2.0은 OAuth1.0의 개선 버전으로, 보다 간단하고 유연한 인증 방식을 채택했다. 이는 현재 가장 널리 사용되는 버전이다.

 

OAuth2.0에서의 역할들

1. Resource Owner

리소스의 소유자로, 인증 절차를 수행한다.

여기서 리소스는, 구글의 캘린더 정보 / 페이스북의 친구 목록 / 네이버의 블로그 포스트 작성 등이 있다.

2. Client

OAuth를 이용하여 Resource Server의 자원을 이용하고자 하는 서비스이다.

Client는 Authorization Server로 부터 인가를 받는다.

3. Authorization & Resource Server

3-1. Authorization Server

인증을 검증하고 인가를 부여하는 주체이다.

Resource Owner의 인증을 완료한 후, 클라이언트에게 액세스 토큰을 발급한다.

3-2. Resource Server

인가 과정을 수행하고, 리소스를 제공하는 주체이다.

액세스 토큰을 활용하여 인가 과정을 수행한 후, 리소스를 제공한다.

 

Authorization Server와 Resource Server는 동일한 서버일 수도 있고, 별도의 서버일 수도 있다.

 

OAuth2.0의 흐름

OAuth2.0의 전반적인 흐름에 대해 알아보자.

(OAuth2.0에서는 총 4종류의 권한 부여 방식을 제공하며, 아래 흐름은 특정 방식의 흐름이 아닌 추상화된 흐름이다.)

1. Client는 Resource Owner에게 인가 요청을 보낸다.
   • 이 때, 인가 요청은 중개자로 Authorization Server를 통해 간접적으로 이루어질 수 있다.
2. Resource Owner는 Client에게 인가 그랜트를 발급한다.
   • 인가 그랜트란, 클라이언트가 리소스에 접근할 권한을 부여하는 자격증명이다.
3. Client는 Authorization Server와의 인증을 수행하고, 인가 그랜트를 사용하여 액세스 토큰을 요청한다.
4. Authorization Server는 클라이언트를 인증하고 인가 그랜트를 검증한후 유효하다면 액세스 토큰을 발급한다.
   • 액세스 토큰은 Client가 Resource Server에 접근할 수 있는 자격 증명이다.
5. Client는 액세스 토큰을 사용하여 Resource Server에게 접근 요청을 보낸다.
6. Resource Server는 액세스 토큰의 유효성을 검증하고, Client가 요청한 리소스에 대한 권한이 있으면 리소스를 제공한다.

 

OAuth의 권한 부여 방식

OAuth2.0은 총 4종류의 권한 부여 방식을 제공한다.

Authorization Code Grant

Client가 Authorization Server로 부터 인증 코드를 받은 후, 이를 사용해 액세스 토큰을 요청한다.

Implicit Grant

Client가 인증 코드 없이 액세스 토큰을 요청한다

Resource Owner Password Credentials Grant

Client가 Resource Owner의 아이디와 비밀번호를 직접 받아 액세스 토큰을 요청한다

Client Credentials Grant

Client 자체의 인증으로 액세스 토큰을 요청한다.

 

 

이 중 Authorization Code Grant가 가장 일반적으로 사용되는 방식이다.

Authorization Code Grant에 대해 자세하게 알아보자.

 

Authorization Code Grant의 흐름

아래는 Authorization Code Grant방식의 동작 흐름이다.

 

사진 출처:  https://hudi.blog/oauth-2.0/

1~2. 로그인 요청

Resource Owner가 로그인을 요청하면, Client는 Client ID, requested scope, local state, redirection URI 와 함께 로그인을 요청한다.

 

3~4. 인증 절차 진행

Authorization Server는 위와 같은 로그인 페이지를 제공한다.

Resource Owner는 자신의 계정 정보를 입력하여 인증 절차를 진행한다.

이 때, Resource Owner는 Client의 액세스 요청을 허용한다.

 

5~6. Redirect with 인증 코드

Authorization Server는 이전에 제공된 redirection URI를 사용하여 리다이렉션한다.

해당 리다이렉션 URI에는 Client가 이전에 제공한 local state와 인증 코드(Authorization Code)가 포함된다.

 

7~8. 인증 코드로 액세스 토큰 요청

Client는 이전 단계에서 받은 인증 코드를 사용하여 Authorization Server에게 액세스 토큰을 요청한다.

요청시 Client는 인증 코드를 검증하기 위해 Authorization Server에 redirection URI를 포함한다.

Authorization Server는 이전 단계에서 수신한 redirection URI가 요청에 포함된 URI와 일치하는지 확인한다.

일치한다면, 액세스 토큰(Access Token)를 응답으로 보낸다. 이 때, 선택적으로 리프레시 토큰도 함께 보낼 수 있다.

9. 로그인 성공

Client는 로그인이 성공적으로 진행됐음을 Resource Owner에게 알린다.

 

10~13. 액세스 토큰으로 리소스 접근

Resource Owner가 Resource Server의 자원이 필요한 기능을 Client에게 요청한다.

이 때, Client는 위 단계에서 발급받은 액세스 토큰을 사용하여 제한된 리소스에 접근하고, Resource Owner에게 서비스를 제공한다.

 

 

---

그동안 소셜 로그인 구현은 몇차례 해봤지만, OAuth에 대한 본질적인 이해는 동반하지 않고 구현에 급급했던 것 같다.

이번 기회에 OAuth2.0에 대한 개념을 자세히 공부하게 되어서 기분이 좋다!

 

참고 자료

- 홍실의 테코톡

RFC 6749: The OAuth 2.0 Authorization Framework

OAuth 2.0 개념과 동작원리