OAuth 프로토콜의 이해와 활용 3 - OAuth 인증방식의 종류

이번 시간에는 OAuth에서 권한 인증을 승인할 수 있는 방식을 알아봅시다.

 

크게 4가지 방식이 있는데요. RFC 6749(OAuth 2.0 Framework)에서 소개된 방식입니다.

 

 

Resource Owner에게 사용 허락을 받았다는 증서인 권한 코드 (Authorization Code)를 가지고 AccessToken을 요청하는 방식입니다.

보통 서버 사이드에서 인증을 처리하는 경우 이 방식을 많이 사용하고,

 

Resource Owner에게 사용 허락을 받은 후 증서를 따로 받고, 이 증서와 함께 요청하는 방식이므로 다른 방식보다 조금 더 복잡합니다.

 

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

 

OAuth 프로토콜의 이해와 활용 2 포스팅에서 보셨던 방식이 바로 이 방식입니다.

 

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

 

---

 

 

 

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

발급된 Access Token은 바로 Redirect URI의 fragment로 붙어서 전송됩니다.

그래서 보통 클라이언트 사이드에서 인증을 처리할 때 많이 사용되는데요.

 

예를 들어, 웹페이지에서 서버를 안거치고 바로 사용자의 구글 드라이브에 있는 파일 목록을 가져오려고 할 때

Ajax를 통해 클라이언트에서 구글(Service Provider)로 Access Token 발행 요청을 하고 Resource Owner가 인증 및 사용 허가를 하면 구글의 인증서버에서는 바로 Access Token을 넘겨줍니다. 이 Access Token으로 바로 파일목록을 가지고 올 수 있죠.

 

별도의 서버 구축 필요 없이 클라이언트 측에서 간편하게 사용할 수 있는 장점이 있죠.

 

대신에, 클라이언트 쪽에 프래그먼트로 바로 토큰이 노출되기 때문에, 상대적으로 보안에 취약합니다.

 

그래서 다른 방식보다 발급되는 Access Token의 유효시간이 짧은 편입니다.

 

 

---

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

 

 

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

회원 정보 통합 정책으로 인해 회원에 관한 모든 정보는 월드그룹의 데이터베이스에서 저장하고 있고, 

인증서버에 권한을 획득 후에 회원정보에 접근할 수 있도록 허용합니다.

 

만약 사용자(Resource Owner)가 월드백화점 사이트에 접속하여 내 배송 현황을 좀 보려고 하는데

자꾸 권한을 허가하라는 창이 뜨면 어떨까요?

많이 귀찮겠죠?

 

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

 

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

 

그러면 바로 Access Token을 발급받아 사용할 수 있습니다.

 

 

---

 

마지막으로 클라이언트 자격증명 방식입니다.

이 방식은 Client와 Resource Onwer가 같은 주체일 때 사용합니다.

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

 

아니 그런데 이런 경우가 있을까요?

Client와 Resource Owner가 같을 때가 있나요?

 

이런 경우를 생각해봅시다.

 

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

 

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

 

한마디로 "저 클라이언트인데요. 제가 올린 파일 주세요" 하는 거랑 똑같은 거죠.

 

그래서 별다른 절차 없이 바로 Access Token을 발행해줍니다.

 

 

---

이렇게 해서 일반적으로 많이 사용하는 권한 승인 방식에 대해 알아보았습니다.

다른 서비스에 구축되어 있는 OAuth 시스템을 사용하려고 할 때는 보통 권한 인증 코드 방식이나, 암시적 방식을 사용하게 됩니다.

 

보통 요청을 보낼 시 response_type으로 구분하여 사용하는데 권한 인증코드는 code, 암시적 방식은 token으로 보내어 요청하게 됩니다.

사용하고자 하는 Service Provider에 따라 이것도 조금씩 다를 수 있으니 사용하고자 하는 API의 문서를 유심히 살펴보시어 맞춰 사용하면 되겠습니다.

 

위의 사진은 OAuth 2.0 공식 홈페이지 (https://oauth.net/2/)에 명시되어 있는 OAuth 권한 승인 방식들입니다.

아래 암시적 방식과 비밀번호 승인 방식이 레거시로 빠져있네요 ㅠㅜ

하지만 레거시 이긴 해도, 아직까지 많이 사용되는 방식이니까 꼭 알아두시고

나머지 2개 방식 (Device Code, PKCE)는 다음 기회에 추가로 포스팅하겠습니다.

 

다음 시간에는 JWT(JSON Web Token) 방식에 대해 알아보겠습니다. 감사합니다.