OAuth2.0

📌 OAuth 2.0 소개

• 다른 서비스의 회원 정보를 안전하게 사용하기 위한 방법이다.
• 고객이 자신의 다른 서비스(네이버, GitHub 등)의 아이디/비밀번호를 우리 서비스에 알려주지 않아도, 다른 서비스(네이버, GitHub 등)에 있는 고객의 정보를 우리 서비스에서 안전하게 사용하기 위한 방법이다.
• 즉, 다른 서비스로부터 AccessToken을 얻어내는 기술이다.
  • 이렇게 얻은 AccessToken을 이용해 해당 서비스의 일부 기능을 이용할 수 있는 것이 OAuth 서비스의 핵심

📌 기술 선정 이유

• 사용자들은 새로운 서비스를 이용할 때마다, 회원가입을 진행하는 일이 번거롭다고 느낀다. (귀찮다고 느끼는 사용자가 많다.)
• 처음 보는 서비스에 대해 신뢰성을 갖기 어렵다.

📌 OAuth 2.0 로그인을 위해 준비해야할 것

• 다른 서비스(네이버, GitHub 등)의 Client ID: public key 이다. 공개해도 된다.
• Client Secrets: secret key이다. 공개하면 안 된다. 우리는 .env에서 관리한다.
• Redirect URL: Client ID와 Client Secret을 확인한 후 redirect할 url 주소이다.

📌 위의 Client ID, Client Secret, Redirect URL은 어떻게 얻는가?

• 각 인증을 요청할 다른 서비스(네이버, GitHub 등)에 어플리케이션을 등록하면 된다.
• ex) GitHub의 경우는 Settings -> Developer settings -> OAuth Apps을 등록하면 된다. 여기서 Homepage URL, Authorization callback URL(Redirect URL), Client ID, Client Secrets 등을 등록 & 확인할 수 있다.

📌 프로젝트에 OAuth 2.0 적용 과정

1. 사용자가 원하는 로그인 방식을 선택하면 -> OAuth Authorize Server에 인증 요청을 보낸다.

---

2. callback url로 리다이렉트

• 사용자가 ID, PW를 입력하면, 어플리케이션 등록 시 적었던 callback url로 지정한 url로 리다이렉트 된다.
• 이 때 url 내에 code 값이 파라미터로 함께 온다.
  • http://118.67.129.125:8080/?code=[:code]

---

3. Access Token 발급

• 2번에서 받은 code 값을 backend로 전달한다.

  • 깃허브 로그인: http://118.67.129.125:3000/user/githublogin
  • 네이버 로그인: http://118.67.129.125:3000/user/naverlogin
  • 카카오 로그인: http://118.67.129.125:3000/user/kakaologin
  
  

• client_id, client_secret, code 값을 OAuth Authorize Server에 access token을 요청한다. (POST 요청)

  • OAuth Token Authorize Server는 세 가지 정보가 모두 일치하는지 확인한다.
  • 모두 일치하면 Access Token을 발급한다.

---

4. 사용자 정보 요청

• 발급 받은 Access Token을 통해, Resource Server에 사용자 정보를 요청한다. (GET 요청)
  • Access Token은 Header에 담아 전송한다.

  ex) https://api.github.com/user
  
  headers : {
      Authorization:'BEARER (access token)'
  }
  

---

5. 로그인/ 회원가입, JWT 토큰 발행

• 사용자 정보가 우리 DB에 있는지 확인하여, 없으면 user 정보를 DB에 저장한다.
• User 정보를 응답 받으면, User ID로, JWT token을 생성한다.
• JWT token을 frontend로 전달한다.

📌 느낀점

• 보안적 이슈 & 고려했던 점
  • JWT token 탈취
  • JWT token에 저장되어있는 정보
    • userId만 저장되어있다.
  • JWT token 길이 자체가 길어서, 악의적으로 서로 주고 받는 거 아닌 이상 탈취 자체가 조금 어려움
  • 탈취 당한 경우, token 안에 들어있는 정보 자체는 userId만 있기 때문에 크리티컬한 정보가 없다.
  • userId를 알더라도, MongoDB에 접근할 수 있는 IP를 IP를 일부로 한정해두어, 실제 User 정보를 얻지 못하도록 방어한다.