OAuth2.0란?

1. OAuth2.0

1) OAuth2의 개념

OAuth2.0(Open Authorization 2.0, OAuth2)는 인증을 위한 개방형 표준 프로토콜입니다.

 

이 프로토콜에서는 Third-Party 프로그램에게 리소스 소유자를 대신해 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식으로 작동됩니다. 구글, 페이스북 등 외부 소셜 계정을 기반으로 간편하게 인증하는 기능입니다. 기존의 인증방식과 달리 인증을 중개해주는 방식이라고 생각하시면 됩니다.

 

소셜 서비스에서 인증(Authentication)을 대신 해주지만 클라이언트 정보가 서버에 저장되는 것은 기존 인증 방식과 동일합니다. 즉, 서버에서 접근 권한 관리(Authorization)은 여전히 서버가 담당해야 할 부분이 됩니다. 그럼에도 불구하고 OAuth 프로토콜을 사용해서 접근 권한 관리, 인증 절차를 간단하게 구현할 수 있습니다.

2) OAuth2의 제공자

• 구글
• 페이스북
• 카카오
• 네이버

3) 역할

이름	설명
Resource Owner	리소스 소유자입니다. 본인의 정보에 접근할 수 있는 자격을 승인하는 주체입니다. 예시로 구글 로그인을 할 사용자를 말합니다. Resource Owner는 클라이언트를 인증(Authorize)하는 역할을 수행하고, 인증이 완료되면 동의를 통해 권한 획득 자격(Authorization Grant)을 클라이언트에게 부여합니다.
Client	Resource Owner의 리소스를 사용하고자 접근 요청을 하는 어플리케이션 입니다.
Resource Server	Resource Owner의 정보가 저장되어 있는 서버입니다.
Authorization Server	권한 서버입니다. 인증/인가를 수행하는 서버로 클라이언트의 접근 자격을 확인하고 Access Token을 발급하여 권한을 부여하는 역할을 수행합니다.

4) 주요 용어

이름	설명
Authentication (인증)	인증, 접근 자격이 있는지 검증하는 단계입니다.
Authorization (인가)	자원에 접글할 권한을 부여하고 리소스 접근 권한이 담긴 Access Token을 제공합니다.
Access Token	리소스 서버에게서 리소스 소유자의 정보를 획득할 때 사용되는 만료 기간이 있는 Token입니다.
Refresh Token	Access Token 만료시 이를 재발급 받기위한 용도로 사용하는 Token입니다.

2. OAuth2.0의 인증 과정

OAuth 2.0 작동 방식

1️⃣ 사용자는 특정 웹 어플리케이션에서 OAuth 서비스를 요청합니다. 웹 어플리케이션(Client)에서는 OAuth 서비스에 Authorization Code를 요청합니다.

 

2️⃣ OAuth 서비스는 Redirect를 통해 Client에게 Authorization Code를 부여합니다.

 

3️⃣ Client는 Server에게 OAuth 서비스에서 전달받은 Authorization Code를 보냅니다.

 

4️⃣ Server는 Authorization Code를 다시 OAuth 서비스에 전달해 Access Token을 전달받습니다.

 

5️⃣ Server는 Access Token으로 Client를 인증하고 요청에 대한 응답을 반환합니다.

3. OAuth2.0의 권한 부여 방식

OAuth 2.0 프로토콜에서는 다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따른 프로토콜을 4가지 종류로 구분하여 제공하고 있습니다.

1)  Authorization Code Grant │ 권한 코드 승인  방식

Resource Owner에게 사용 허락을 받았다는 증서인 권한 코드 (Authorization Code)를 가지고 AccessToken을 요청하는 방식입니다. 보통 서버 사이드에서 인증을 처리하는 경우 이 방식을 많이 사용하고, Resource Owner에게 사용 허락을 받은 후 증서를 따로 받고, 이 증서와 함께 요청하는 방식이므로 다른 방식보다 조금 더 복잡합니다.

 

대신 다른 방식보다 좀 더 신뢰성이 있는 방식이라 발급되는 액세스 토큰의 유효시간이 좀 더 길고, 다시 액세스 토큰을 발급받을 수 있는 Refresh Token을 함께 발급해 줍니다.

 

권한 코드(Authorization Code)를 간단히 정리하자면 아래와 같습니다.

2) Implicit Grant │ 암시적 승인 방식

이 방식은 추가적인 절차 없이 Resource Owner가 인증 및 허가를 하면 바로 Access Token이 발급되는 방식입니다.

발급된 Access Token은 바로 Redirect URI의 fragment로 붙어서 전송됩니다. 그래서 보통 클라이언트 사이드에서 인증을 처리할 때 많이 사용됩니다.

 

예를 들어, 웹페이지에서 서버를 안거치고 바로 사용자의 구글 드라이브에 있는 파일 목록을 가져오려고 할 때 Ajax를 통해 클라이언트에서 구글(Service Provider)로 Access Token 발행 요청을 하고 Resource Owner가 인증 및 사용 허가를 하면 구글의 인증서버에서는 바로 Access Token을 넘겨줍니다. 이 Access Token으로 바로 파일목록을 가지고 올 수 있죠.

 

별도의 서버 구축 필요 없이 클라이언트 측에서 간편하게 사용할 수 있는 장점이 있습니다. 대신에, 클라이언트 쪽에 프래그먼트로 바로 토큰이 노출되기 때문에, 상대적으로 보안에 취약합니다. 그래서 다른 방식보다 발급되는 Access Token의 유효시간이 짧은 편입니다.

3) Resource Owner Password Credentials Grant │ 리소스 소유자 비밀번호 자격 증명

Client와 Service Provider가 절대적으로 믿을 수 있는 관계일 때 사용하는 방식입니다.

예를 들어, 월드그룹이라는 회사가 있고, 그 아래에 월드 홈쇼핑과 월드백화점이라는 계열사가 있다고 생각해봅시다.

 

회원 정보 통합 정책으로 인해 회원에 관한 모든 정보는 월드그룹의 데이터베이스에서 저장하고 있고,  인증서버에 권한을 획득 후에 회원정보에 접근할 수 있도록 허용합니다.

 

만약 사용자(Resource Owner)가 월드백화점 사이트에 접속하여 내 배송 현황을 좀 보려고 하는데 자꾸 권한을 허가하라는 창이 뜨면 어떨까요? 많이 귀찮겠죠?

 

월드그룹 입장에서 월드백화점은 분명히 믿을 수 있는 관계니까 굳이 Client가 믿을 수 있는지, 사용자에게 리소스 사용 허가를 받았는지는 중요하지 않을 겁니다.

 

이럴 때 월드백화점에서는 로그인할 때 받은 사용자의 username과 password를 가지고 바로 월드그룹의 인증서버에 Access Token을 요청합니다. 그러면 바로 Access Token을 발급받아 사용할 수 있습니다.

4) Client Credentials Grant │ 클라이언트 자격증명 승인 방식

마지막으로 클라이언트 자격증명 방식입니다. 이 방식은 Client와 Resource Onwer가 같은 주체일 때 사용합니다.

그래서 인증서버에서는 별도의 권한 허가 확인 없이 바로 Access Token을 발행해줍니다.

 

그런데 이런 경우가 있을까요? Client와 Resource Owner가 같을 때가 있나요?

 

예를 들어 우리가 만든 커뮤니티 사이트에서 사용하는 이미지나, CSS, JS파일 같은 구글 클라우드 서비스에 올려놓고 사용한다고 가정해 봅시다.

 

이 경우 구글 클라우드(Service Provider) 입장에서는 Client와 Resource Owner는 같은 개념이 됩니다.

 

한마디로 "저 클라이언트인데요. 제가 올린 파일 주세요" 하는 거랑 똑같은 거죠. 그래서 별다른 절차 없이 바로 Access Token을 발행해줍니다.

 

[참고]

https://gdtbgl93.tistory.com/181

https://charming-kyu.tistory.com/36