OAuth
3명의 주체
mine(나의 서비스)
User(서비스 이용자)
their(Google, Facebook, Twitter) - ID, PW
OAuth 적용시
User
Their - accessToken
Resource Owner
mine(Client)
둘이 분리되어 있긴 하지만, 여기서는 Resource Server로 통칭
Resource Server -
(Data를 가지고 있는 서버)
Authorization Server
(인증 처리를 위한 서버)
- 권한 코드 승인 방식(Authorization Code Grant Type)
Resource Owner에게 사용 허락을 받았다는 증서인 권한 코드 (Authorization Code)를 가지고 AccessToken을 요청하는 방식입니다.
보통 서버 사이드에서 인증을 처리하는 경우 이 방식을 많이 사용하고,
Resource Owner에게 사용 허락을 받은 후 증서를 따로 받고, 이 증서와 함께 요청하는 방식이므로 다른 방식보다 조금 더 복잡합니다.
대신 다른 방식보다 좀 더 신뢰성이 있는 방식이라 발급되는 액세스 토큰의 유효시간이 좀 더 길고, 다시 액세스 토큰을 발급받을 수 있는 Refresh Token을 함께 발급해 줍니다.
OAuth 프로토콜의 이해와 활용 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의 유효시간이 짧은 편입니다.
-
리소스 소유자 비밀번호 자격 증명
Client와 Service Provider가 절대적으로 믿을 수 있는 관계일 때 사용하는 방식입니다. -
클라이언트 자격 증명 방식
마지막으로 클라이언트 자격증명 방식입니다.
이 방식은 Client와 Resource Onwer가 같은 주체일 때 사용합니다.
그래서 인증서버에서는 별도의 권한 허가 확인 없이 바로 Access Token을 발행해줍니다.
아니 그런데 이런 경우가 있을까요?
Client와 Resource Owner가 같을 때가 있나요?
이런 경우를 생각해봅시다.
예를 들어 우리가 만든 커뮤니티 사이트에서 사용하는 이미지나, CSS, JS파일 같은 구글 클라우드 서비스에 올려놓고 사용한다고 가정해 봅시다.
이 경우 구글 클라우드(Service Provider) 입장에서는 Client와 Resource Owner는 같은 개념이 됩니다.
한마디로 "저 클라이언트인데요. 제가 올린 파일 주세요" 하는 거랑 똑같은 거죠.
그래서 별다른 절차 없이 바로 Access Token을 발행해줍니다.
