우선 포스팅을 시작하기에 앞서서 확실히 짚고 넘어갈 부분을 이야기해보자.
이 포스트에서는 소셜로그인의 장단점을 이야기하고자하는 것이 아니라, 소셜로그인에 필요한 OAuth2를 이야기해보고
근본적으로 왜 OAuth를 사용하게 되었고 로그인과는 어떤 차이점이 있는지알아보기로 하자.
소셜 로그인은 왜 할까 ❓
가령 어떤 웹 서비스를 만들기 위해 개발중인 개발자 호준김이 있다고 해보자. 호준김은 서비스 확장성과 용이성을 위해서 아래와 같은 기능을 추가하고 싶었다.
"우리 웹 서비스의 확장성을 위해서 다른 서비스 제공자가 제공해주는 서비스를 사용하고 싶은데.."
그런데 호준김은 페이스북에게서 모든 기능들을 가져오고자 하는것이아니라 친구 목록을 가져오는 API에 대해서만 받고 싶었다.
열심히 구글링을 한 호준김은 OAuth2을 통해서 특정 서비스를 가져올 수 있다는것을 알았다. 그런데 막상 구현을 해보니까 소셜로그인을 해야만했고 왜 로그인을 해야하는지 이해가 되지 않았다.
이에 대해서 OAuth2를 모르는 호준김은 다음과같은 고민에 빠졌다.
- 소셜 로그인을 통해서 우리 웹사이트를 이용할 수 있으니까 내가 만든 서비스의 회원인건가?
- 나는 특정 서비스를 사용하고자 OAuth를 사용한건데, 왜 로그인을 하지?
- 로그인과 소셜로그인의 차이가 뭐지??
이 의문을 해결하기 위해서는 OAuth2에 대해서 이해가 필요하다.
OAuth 2
OAuth는 사용자가 3rd party Application에게 특정 권한을 일임할 것인지 확인을 위해 애플리케이션이 아닌 API 제공 서비스에 로그인하는 것이다.
OAuth가 있기 전에도 외부 API 제공 서비스를 사용할 수 있었다. 다만 외부 인증에 대해 모두 다른 방식을 가지고 있었기에 표준을 만들 필요가 요구되었다. 그렇게 OAuth 1.0을 거쳐서 현재의 OAuth2가 탄생했다.
OAuth는 로그인과 다른게 뭔가요..?
일반 로그인과 다르다는 점을 분명히 해야한다. 위에서 OAuth를 정의할 때도 언급했지만, API 제공 서비스에 로그인 하는 것이다. 이를 이해하기 위해서는 용어 두가지, 'Authentication'(인증)과 'Authorization'(허가)를 알아야 할 필요가 있다.
Authentication
Authentication(인증)은 우리가 흔히 말하는 로그인이다. 즉, 특정 웹서비스의 클라이언트는 개별적인 컨텐츠를 소유하며 그 컨텐츠를 얻기위해서 서버측에 요구할 때 인증(로그인)이 필요하다.
더 자세한 내용을 알고싶다면 로그인은 어떻게 이루어질까❓(Cookie, Session)를 참고하자.
Authorization
인증이 된 클라이언트의 정보를 3rd party Application에게 특정 권한을 일임할 것인지 확인하는 절차를 허가라고 한다. 우리가 소셜로그인을 할 때 개인정보 중 일부가 3rd party Application으로 넘어가는 것을 동의하는 탭을 본적이 있을텐데, 이 부분을 허가라고 할 수 있다.
즉, OAuth에는 Authentication과 Authorization 모두를 포함하지만, 근본적인 목적은 허가를 통해서 특정 API 제공 서비스를 얻기 위함이다.
여기까지 와서야 호준김은 앞서 들었던 의문이 해결되었다고 한다.
- 소셜 로그인을 통해서 로그인을 한다면 내가만든 웹 사이트에서 특정 서비스만 이용할 수 있구나
- OAuth를 사용하면 본디 목적은 특정 서비스를 사용하고자하는 것이지만
인증또한 불가피하구나 - 로그인과 소셜로그인은 목적이 다르고 소셜로그인은 제한이 있구나
구현
호준김이 OAuth를 구현하는 것이 우선순위는 아니니 구현은 나중으로 미뤘다고 한다..
REF
