WIL #14 소셜로그인기능 1

🤷 기간 : 2021.05.24 ~ 2021.05.24
🤷 자료 :

• https://velog.io/@hyunju-song/%EC%86%8C%EC%85%9C%EB%A1%9C%EA%B7%B8%EC%9D%B8%EA%B8%B0%EB%8A%A51OAuth,
• https://velog.io/@parkoon/OAuth-%EC%99%84%EB%B2%BD%ED%95%98%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0
• https://libertegrace.tistory.com/entry/40-Authentication-OAuth-20?category=869766
  🤷 내용: 소셜로그인기능 원리 및 절차

---

소셜로그인 구현원리

용어설명

• client
  • 소셜로그인 기능을 사용하는 주체(=resource server을 사용하려는 주체), 서비스를 만드는 바로 '나'임
  • 내가 그 소셜로그인 기능을 사용하는 클라이언트다
• resource owner
  • 소셜로그인 기능을 제공하는 서비스를 사용하는 유저(진짜 로그인하려는 사람임)
  • 이미 카카오에 가입된 사람들이며, 카카오(resource server) 소셜로그인을 통해 들어오려고 하는 사람
• resource server(카카오, 네이버, 구글 등)
  • 소셜로그인 기능을 제공하는 곳이며, 그 기능을 제공하기 위한 데이터를 가지고 있는 서버
  • 실질적으로 유저 데이터들을 가지고 있는 서버

절차

1. 사용자가 소셜로그인 버튼(카카오로그인, 네이버로그인 같은 것)을 누르면, 로그인 하고자 하는 소셜(카카오, 네이버)의 로그인 페이지로 이동
2. 소셜의 로그인 페이지로 가기위해, client(서비스 제공자)와 resource server(소셜(=카카오,네이버))사이에서 뭔가 상호작용이 일어나고, 이 상호작용을 위해 client(서비스 제공자)는 미리 OAuth라는 서비스를 사용한다.
3. 로그인 성공 후, resource server(소셜)은 사용자의 페이지가 기존에 사용하던 서비스 페이지(client가 만든 서비스 페이지)로 redirect 되도록 해준다.

긍까, 소셜로그인은 카카오나 네이버(resource server)에서 나(client)라는 제공자와 서비스 사용자(recource owner) 사이에서 로그인을 중개하주는 역할
-> 그리고 이 중개자의 역할을 하게 해주는 서비스가 OAuth 이다

• 사용자가 소셜로그인에 로그인했을 떄,
  • 단순히 사용자의 아이디와 패스워드를 클라이언트에게 주고 공유하는게 아님
    • 그럼 사용자가 넘 불안하자너 .;;;;
  • OAuth를 거쳐서, resource server는 client에게 Access Token을 제공
    • OAuth를 거치면 "사용자가 사용하고 싶은 앱/웹 "와 "로그인을 중개해주는 카카오, 구글 같은 소셜'간의 서비스를 안전하게 상호작용하며 사용할 수 있다.
  • client는 이 Access Toeken을 통해서 resource server에 접근할 수 있게되고,
  • resource owner에게 로그인 페이지를 제공할 수 있따.

***Access Token의 장점이 뭐길래?

반복된 말이지만,
1. 일단 쌩판 동일한 아이디, 비번을 제공하는게 아니고
2. '카카오 구글 같은 소셜'의 모든 기능이 아니라 그 중 '내가 사용하고 싶은 웹/앱' 에 꼭 필요한 기능만 부분적으로 접근 허용할 수 있다.

세부절차

1. clinet가 resource server에 접근을 위해서 client는 resource server에 등록해야한다

• 등록은 KaKao Developer, Facebook Developer, Google Developer 와 같은 소셜(resource server) 자체사이트에서 진행한다.(https://developers.kakao.com/docs/latest/ko/kakaologin/prerequisite)
• ***절차 등록을 진행하며, clinet와 resource server는 3가지 정보 공유한다.
  • Client Id
    • Client(=내가 구현할 어플리케이션(서비스))의 식별 ID
  • Client Secret
    • 실제로 resource server에서 Client(=내가 구현할 어플리케이션(서비스))가 맞는지 식별할 수 있는 비밀번호(**절대 코드에 노출되면 안되는 정보이며, 보안이슈가 심각하다)
  • Authorized Redirect URL
    • Resource Server에서 client에게 인증이 가능하도록 권한을 부여하는 과정에서 인증코드(Authorized Code)를 전달해 줄 경로
    • Authorized rediret URIs로 Authorized Code 전달해줘~

2. Resource Owner가 Resource Server에게 Client의 접근을 승인하는 과정

Client가 Resource Server의 모든 기능이 아니라 몇가지 필요한 기능만 사용하면 된다면, 그 몇가지 필요한 기능의 사용 인증만 받은면 된 다 !

• Resource Owner가 Client에서 Resource Server 기능 A~Z중에서 A,B기능만을 사용하려고 한다면,
  • Client는 특정형식의 주소를 가지는 버튼(카카오 로그인 노란색으로 되어있는 그런 버튼)을 제공한다
• Resource Owner가 그 버튼을 누르면 Resource Server는 그 버튼을 누른 Resource Owner가 현재 Resource Server에 로그인되어있는지 확인하고,
  • 되어있다면 -> Resource Server는 Resource Owner가 타고들어온 버튼(link)에 담겨진 client id값을 확인 한다. server등록되어있는 client id와 비교)
  • 되어있지 않다면 -> 로그인 화면 보여주고, 로그인 하라고 한다. -> clinet id 값 확인
    - client id 값이 확인 후 로그인 완료
• 로그인 완료 후, Resource Server는 Resource Owner가 타고들어온 버튼(link)에 담겨진 redirect url값을 확인 한다. server등록되어있는 redirect url와 비교)
  • 확인 안되면 -> 종료
  • 확인 되면 -> Resource Server 는 Resource Owner 에게 Scope을 확인 하는 창을 띄어준다.
    • 그 버튼 주소의 scope에 해당하는 권한을 client에 해용하는지 확인 하라고 . !
    • Scope 란 ? Client가 Resource Server 에서 사용할 자원들(정보들)을 말한다.
• Resource Owner가 권한을 허용한다고 하면, 그 허용 응답이 Resource Server에게 간다
• Resource Server는 user id와 Scope 정보를 추가로 가지게 된다.
  • user id : 버튼(link)에 담겨있던 Client Id 값
  • Scope : B,C
    - Resource Owner가 허락해 접근 할 수 있는 리소스 목록
    
    

3. Resource Server이 승인하는 과정

사용자(Server Owner)의 허락을 받았으니 Resource Server에 승인을 받아야한다 !

• Authorization Code를 Resource Server가 response의 header에 location: https://[redirect URL]?code=[Authorization Code]이라는 값을 주어 redirect하도록 한다.
  
• Resource Owner의 위치는 loaction에 담긴 주소로 이동하게 되는것(redirect되는 것)
• 그러면서 Client는 redirect URL뒷부분에에 params형태로 담긴 authorization code를 알게된당
  
• 이렇게 Resource Server가 가진 Authorization code를 Client도 가지게 되면, Client는 아래 그림과 같은 형식의 주소로 Resource Server에 직접 접속한다.
  • ex) https://resource.server/token?grant_type=authorization_code&code=3&redirect_uri=https://client/callback&client_id=1&client_secret=2
    
• Resource Server는 Client가 전송한 주소에 있는 Authorization code와 client ID, client secret, redirect URL이 Resource Server 자신이 가지고 있는 정보들과 일치했을 때 ! ?
• Resource Server는 이제서야 Access Token을 발급한다

4. Access Token을 발급받는 과정★

• Resource Server와 Client는 승인이 다 되었으므로 앞으로 중복 인증을 피하기 위해 Authorization code를 지운다. 그리고 Resource Server는 Access Token을 발급했다!
• 발급한 Access Token을 client에게 전달해주고, Client는 Access Token을 저장한다.
  

Access Token이 어떻게 활용되나 ?

• Client가 발급된 Access Token으로 Resource Server에 접근하고,
• Resource Server는 Access Token을 보고,
  • 'user id가 ~인 사용자의 정보에 대해서 scope ~,~ 을 허용' 한다. !

Refresh Token

• accessToken의 수명을 그리 길지 못하다. 짧게는 1시간 길게는 몇일 정도로 설정되어 있다. accessToken의 수명이 모두 끝나면 더 이상 Resource Server에 접근 할 수 없게되고, 위의 1~10번의 과정을 다시 거쳐야 한다.

이 과정을 생략하기 위해 필요한 것이 Refresh Token 이다.