OAuth
웹이나 앱에서 흔히 찾아볼 수 있는 소셜 로그인 인증 방식은 OAuth 2.0라는 기술을 바탕으로 구현된다.
- 전통적으로 직접 작성한 서버에서 인증을 처리해주는 것과는 달리, 인증을 중개해주는 메커니즘
- 보안된 리소스에 엑세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜
- 이미 사용자 정보를 가지고 있는 웹 서비스(Naver, Kakao, Google 등)에서 사용자의 인증을 대신해주고, 접근 권한에 대한 토큰을 발급한 후, 이를 이용해 내 서버에서 인증이 가능해짐
OAuth 작동 메커니즘
OAuth의 주체
Resource Owner: OAuth 인증을 통해 소셜 로그인을 하고싶어하는 사용자
Resource는 사용자의 이름, 전화번호 등의 정보를 뜻함. 이러한 정보의 주인이 바로 사용자이기 때문에 Resource Owner라고 함.
Resource Server : 사용자가 소셜 로그인을 하기 위해서 사용중인 서비스(Naver, Kakao, Google 등)의 서버 중 사용자의 정보를 저장하고 있는 서버
Authorization Server: 이미 사용중인 서비스의 서버 중 인증을 담당하는 서버
Application: 사용자가 소셜 로그인을 활용해 이용하고자하는 새로운 서비스. 클라이언트와 서버가 포함.
OAuth 인증 방식의 종류와 흐름
-
Implicit Grant Type
기존 서비스에 로그인만 되어있다면 새로운 서비스에 바로 액세스 토큰을 내어주기 때문에 보안성이 조금 떨어지기 때문에 소셜 로그인에서 Implicit Grant Type은 잘 사용하지 않는다. 보통은 여기에 인증 단계를 한 단계 추가한 Authorization Code Grant Type을 주로 사용한다.
-
Authorization Code Grant Type
Implicit Grant Type과 비교해보면, Authorization Code를 사용한 인증 단계가 추가로 있기 때문에 비교적 더 안전하다.
-
Refresh Token Grant Type
Authorization Server로 리프레시 토큰을 보내주면, Authorization Server는 리프레시 토큰을 검증한 다음 액세스 토큰을 다시 발급해준다.
OAuth의 장점
-
쉽고 안전하게 새로운 서비스를 이용할 수 있다.
- 정보를 해당 서비스에 직접 노출하는 것이 아니기 때문에 직접 가입하는 것보다 더 안전하며, Application의 입장에서도 회원의 정보를 직접 가지고 있음으로 인해서 발생할 수 있는 회원 정보 유출의 위험성에서 부담을 덜 수 있다.
-
권한 영역을 설정할 수 있다.
- OAuth 인증을 허가한다고 해서 새로운 서비스가 사용중이던 서비스의 모든 정보에 접근이 가능한 것은 아니다. 사용자는 원하는 정보에만 접근을 허락할 수 있어 보다 더 안전하다.
Q. OAuth는 인증(Authentication)과 접근 권한관리(Authorization)까지 다른 서비스에게 맡기기 때문에 서버의 역할을 분담시켜줄 수 있다?
- 아니다. OAuth는 인증(Authentication)을 다른 서비스에 맡길 뿐, 접근 권한 관리(Authorization)는 내 서버에서 해주어야 한다.
