소셜 로그인

소셜로그인

Social Sign-in 또는 Social Sign-on 이라고도 하는 소셜 로그인은 SNS의 사이트의 정보를 이용해 타사 애플리케이션과 플랫폼에 손쉽게 로그인할 수 있는 프로세스

• 소셜로그인을 사용하면 계정을 만들 필요 없이 편리하고 로그인 및 회원가입 절차를 간소화할 수 있음.

사용자관점
자격 증명을 따로 만들 필요 없이 번거로운 등록 절차를 건너뛰어서 사이트와 앱에 원활하게 액세스 할 수 있음
개발자 및 기업의 관점
사용자 확인을 간소화하는 동시에 개인화를 목적으로 사용자 데이터에 더욱 안정적으로 액세스할 수 있는 방법을 제공해줄 수 있음

소셜 로그인 구성 요소
1) client : 소셜로그인 기능을 사용하는 주체, 즉 서비스를 만드는 "나"
2) resource owner : 소셜로그인 기능을 제공하는 서비스를 사용하는 유저. 어떻게 보면 진짜 고객 인것!
3) resource server : 소셜로그인 기능을 제공하는 곳, 그리고 그 기능을 제공하기 위한 데이터를 가지고 있는 진짜 서버. 일종의 우리가 만드는 서비스의 서버 기능을 하는 것 : 구글, 카카오, 네이버, 깃허브

간단 작동 원리
1) 사용자가 앱 또는 사이트에 접속하여 원하는 소셜 네트워크를 선택한다. 이때, 일반적으로 소셜 로그인 버튼으로 구현을 해놓는다. 이 버튼을 선택하면 사용자는 로그인하고자 하는 소셜의 로그인 페이지로 이동한다
2) 이때 이 로그인 페이지로 가게 하기 위해, 서비스 제공자와 소셜 사이에서의 모종의 상호작용이 일어난다.

이 상호작용을 위해 서비스 제공자는 미리 OAuth라는 서비스를 이용한다

3) 로그인을 성공하면 소셜은 사용자의 페이지가 기존에 사용하던 서비스 페이지로 리다이렉트 시켜준다.

즉, 소셜로그인은 구글 / 카카오 등에서 사용자와 제공자 사이의 로그인 중개 역할을 해주는 것이고, 이 역할을 가능하도록 해주는 서비스가 OAuth이다.

OAuth

OAuth란?
-> 사용자로부터 id, pw 등 보안상 중요한 정보를 입력받아서 사용하는 것이 아니라 구글, 깃허브 등 소셜 서비스에 accessToken 발급해주는것
-> 이 발급된 토큰을 가지고 토큰의 권환을 확인한 후 특정 작업들을 수행할 수 있게 해줌: 서비스 제공자에게 데이터 전달 받기!
-> 즉, 기본적으로 서비스 제공자(구글, 깃허브 등)가 신뢰할 수 없는 타 어플리케이션에게 사용자의 id, pw등을 제공하지 않더라도 사용자의 특정 정보에 접근하거나 작업을 처리할 수 있게 해주는 방법임
-> 이를 사용해서 비밀번호 보안 유지 등의 작업을 소셜 쪽에서 부담하게됨

OAuth 구성요소

OAuth와 기본 로그인의 차이점
일반 로그인과 다르다는 점을 분명히 해야한다. OAuth는 일반 로그인이 아닌 API 제공 서비스에 로그인 하는 것이다. 이를 이해하기 위해서는 용어 두가지, 'Authentication'(인증)과 'Authorization'(허가)를 알아야 할 필요가 있다.

• Authentication

  • Authentication(인증)은 우리가 흔히 말하는 로그인이다. 즉, 특정 웹서비스의 클라이언트는 개별적인 컨텐츠를 소유하며 그 컨텐츠를 얻기위해서 서버측에 요구할 때 인증(로그인)이 필요하다.

• Authorization

  • 인증이 된 클라이언트의 정보를 3rd party Application에게 특정 권한을 일임할 것인지 확인하는 절차를 허가라고 한다. 우리가 소셜로그인을 할 때 개인정보 중 일부가 3rd party Application으로 넘어가는 것을 동의하는 탭을 본적이 있을텐데, 이 부분을 허가라고 할 수 있다.

즉, OAuth에는 Authentication과 Authorization 모두를 포함하지만, 근본적인 목적은 허가를 통해서 특정 API 제공 서비스를 얻기 위함이다.

소셜 로그인 과정

기본적으로 Client id, Client secret, Redirect URls 등록해놨다고 가정한다

• Client id : 내가 구현할 서비스의 식별 ID
• Client 실제로 소셜서비스가 "나"라는 서비스가 맞는지, 옳은 서비스가 접근하여 로그인을 하려고 하는지 식별하는 pw(보안이슈로 절대절대 노출되면 안된다.)
• Authorized Redirect URL : 소셜 서비스가 인증이 가능하도록 권한을 부여하는 과정에서 그 인증코드(Authorized Code)를 전달해줄 경로

1.ResourceOwner가 Client가 제공하는 특정 주소로 요청
2. ResourceServer는 Client id, Client secret을 비교
2-1. 같다면 ResourceServer는 ResourceOwner에게 scope에 해당하는 정보를 Client에게 제공할 것인지를 물음
3. ResourceOwner가 허용하면 ResourceServer는 특정 ResourceOwner(user id)가 Client(client id)에게 scope b, c를 허용하는 것에 동의하였다는 정보를 서버에 저장
4. ResourceServer는 authorization code와 함께 리다이렉션 응답을 보냄
5. Client는 client id, client secret, redirect url, authroization code와 함께 ResourceOwner를 통하지 않고 ResourceServer에 직접 접근
6. ResourceServer는 authroziation code에 해당하는 정보를 Client가 보낸 정보와 비교
7. 모두 일치한다면 accessToken 발급 후 Client에게 응답
8. Client는 accessToken을 내부적으로 저장
9. 이제 Client에서 ResourceServer에 유효한 accessToken을 넘기면 user id가 xxx이고 scope=b, c인 정보에 대해 접근할 수 있음

조금 쉽게 말하자면,
1) 소셜 서비스 접근 위해 client id, client secret, redirect url을 등록을 하여 소셜 로그인과 내가 공유한다
2) 사용자가 소셜 로그인 버튼을 누르면 로그인 하고자 하는 사용자의 승인을 받는다.

• 소셜 서비스에 사용자가 이미 로그인 되어있는 경우
  : 소셜서비스는 사용자가 타고 들어온 서비스의 사이트에 담겨져 있는 Client Id를 점검
• 사용자가 로그인 되어있지 않은 경우
  : 로그인 화면 보여줘서 소셜 서비스 로그인 시킴

3) 로그인 완료 후, 사용자가 타고 들어온 서비스에 담겨진 redirect url을 비교해서 소셜 서비스에서 해당 url 가지고 있다면 사용자에게 서비스 제공자에게 로그인 허용하는 지에 대한 메시지 띄운다.
-> 서비스 제공자는 그 응답에 담긴, 즉 사용자의 소셜 로그인에 대한 데이터를 소셜서비스로부터 받는다.
ex) user id : [링크에 담겨있던 client id값], scope:[그 링크에 담겨 있던 scope]

4) 사용자 승인 받았으니 소셜로부터 승인 받는다
4-1) Authorization Code를 소셜 서비스가 서비스 사용자에게 제공하는 응답의 header에 location: 'https://[redirect URL]?code=[Authorization Code]'이라는 값을 주어 redirect하도록 한다.
4-2) location으로 인해 서비스 사용자는 해당 주소로 리다이렉트 된다
4-3) 서비스 제공자, 즉 나는 리다이렉트로 넘어온 url 뒤의 params 형태로 담긴 authorization code를 알게된다.

-> 이때 서비스 제공자가 소셜 서비스로 접속할 때 가지고간 주소링크에서 Authorization code, Client id, Client secret, redirect URL 이 모두 일치하는지 확인 후 일치하면 Acess Token 발급

5) Access Token 받았으므로 Authorization code지우고 서비스 제공자는 어세스토큰을 따로 저장한다.

6) 이후에는 소셜서비스는 access token을 통해 'user id가 ~~인 사용자의 정보에 대해서 scope ~, ~ .. 을 허용'한다.

원리는 대략 알았으니 다음 포스트에선 실제 깃허브 소셜로그인을 구현하면서 동작 원리를 이해해보도록 하자!