OAuth

OAuth(Open Authorization)

쿠키, 세션, 토큰 방식에 이어 이번에는 OAuth 방식이다.
우리는 평소에 로그인(인증)을 정말 많이 하고 있다. 그렇기에 사용자 눈에 보일정도로 작동 방식에 차이가 있다면, 어떤 차이가 있는지 비교적 쉽게 이해할 수 있다.

우리가 평소에 OAuth방식의 인증을 접하는 순간은 바로 다른 서버의 계정을 연동하는 것이다. 이 방식은 소셜 로그인으로도 불린다.

위 사진만 봐도 어떤 개념인지 대충 감이 잡힌다.

작동 방식

OAuth 방식은 크게 세 가지의 주체가 함께 동작한다.

• 사용자 (Owner)
• 사용할 서비스인 애플리케이션 (application)
• 사용자가 이미 가입한 서비스
  • Resource Server : 리소스를 저장해놓은 서버
  • Authorization Server : 인증을 담당하는 서버

사용자가 애플리케이션에서 로그인 버튼을 누르면 Authorization Server가 확인 후 요청에 따른 리소스를 애플리케이션을 통해 전달하는 방식으로 작동한다. 크게 3가지 종류가 있지만 안전상 문제로 사용이 지양되는 한가지를 제외하면 다음과 같다.

• Authorization Code Grant Type
• Refresh Token Grant Type

Authorization Code Grant Type

• 사용자의 로그인 요청
• 애플리케이션이 사용자에 대한 인증을 요청
• Authorization Server가 확인 후 애플리케이션에 Authorization Code 전달
• 애플리케이션이 Authorization Code을 통해 Authorization Server로 부터 Access Token 취득
• 이후 요청에 Access Token을 같이 전달해 Resource Server로 부터 받은 리소스를 사용자에게 전달

Authorization Code를 통해 추가로 인증을 진행하기 때문에 비교적 안전하고, 원한다면 Access Token을 사용자에게 노출시키지 않는 방법 등도 존재하기에 구현의 자유도가 있는 편이다.

말이 나온김에 사용자에게 Access Token을 노출하지 않는 흐름도 보자

client는 Authorization Code를 local server에 전달하기만 하기 때문에 Accesss Token을 직접 가지지 않는다.

Refresh Token Grant Type

말 그대로 Refresh Token을 기반으로 하는 방법이다.
애플리케이션이 Refresh Token을 통해 Authorization Server에게 Access Token을 받고 그 토큰을 통해 리소스를 얻는다.

장점

위에서 언급한 내용들을 통해 다음과 같은 장점을 알아낼 수 있다.

• 사용자 관점의 손쉬운 가입 : 회원가입 절차를 생략하고, 관리해야할 비밀번호가 추가되지 않음으로 애플리케이션 이용 결정에 부담이 줄어든다.

• 추가적인 정보 전달 X : 사용자 입장에서 사용하는 애플리케이션에 개인정보를 직접적으로 노출하지 않음으로써 직접 가입하는 것보다 안전하다.

• 애플리케이션 입장에서의 쉬운 안정성 : 회원의 정보를 직접 가지지 않기 때문에 회원 정보 유출에 대한 부담이 덜어진다.

• 권한 설정 : OAuth 설정 페이지에서 애플리케이션에 필요한 정보를 선택 가능함으로써 사용자는 원하는 정보를 골라 선택적으로 제공할 수 있다.

역시 가장 마음 편한건 다른 곳에 맡겨버리는거다.
물론 장점만 존재하지는 않기 때문에 OAuth가 무조건 최고다. 는 아니다.

개인적으로 인증/보안이 관심이 가는 부분이라 인증/보안은 추가적으로 공부를 할 생각이다.
앞으로 인증/보안 관련해서도 많은 공부가 필요할거 같다.

평소에 저 소셜 로그인은 어떻게 만들까 라는 궁금증이 있었는데 이번에 공부하면서 어느정도 윤곽을 잡은것 같아서 만족스럽다.