로그인(인증/인가) 방식

쿠키

• 사용자가 아이디와 비밀번호를 서버에 전달하면, 서버는 이에 부합하는 unique한 값을 응답함
  (DB에 저장된 memberID)
• 사용자는 서버로부터 받은 유니크한 값을 통해, 서비스 요청을 함
• 장점
  • 구현이 간단한다.
• 단점
  • 쿠키값을 임의로 조정하여, 다른 사용자처럼 위장하여 접근할 수 있다.

JWT

• 장점
  • stateless하여, 서버의 부하를 줄일 수 있는 장점이 있음
• 단점
  • 토큰을 클라이언트단에 저장하여, 토큰 탈취의 위험이 있음
  • -> 보완 : AT는 서비스요청용, RT는 토큰재발급용으로 하여, AT의 유효기간을 짧게하여 탈취되더라도 유효성을 잃게 함

Session

• stateful, 로그인한 사용자에 대해 sessionId를 부여하고, 이를 서버에 저장
• 서버에 저장된 sessionId가 적합한 경우, request실행
• 장점
  • sessionId는 아무 의미가 없어, 해석하더라도 아무 정보를 얻을 수 없음
• 단점
  • 사용자가 많을 경우, 서버의 부하가 많이 발생하게 됨
  • 서버의 Scale-out시, 동기화의 문제
  • JWT방식과 동일하게, sessionId를 탈취하여 서비스의 사용이 가능함
  • 보완 : sessionId의 시간을 짧게하여, 유효성을 잃게 함

OAuth 2.0

• OAuth 2.0은 다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜로, 주로 소셜서비스 계정을 통해 서비스의 인증/인가를 합니다.
• 장점
  • 사용자의 아이디/비밀번호가 서버에 저장되지 않아, 개인정보 유출에 안전
  • 사용자는 매번 로그인할 때마다, 아이디와 비밀번호를 입력하지 않아도 되는 사용자의 편의성이 높아짐
• 단점
  • 로그인 기능이 타 서버의 영향을 받음 (로그인 서버 다운시, 로그인기능 마비)
  • (OAuth서비스 제작사 입장)OAtuth서비스는 구현하기 복잡하여, 취약점이 존재할 수 있음
    -> 내 서비스가 영향을 받을수 있음

결론

• 많은 서비스에서는 JWT/session + OAuth 2.0 방식을 도입하고 있다. (개인적인 생각)

• 쿠키 방식은 보안적으로 너무나 취약하기 때문에, 현재로는 사용되지 않는다.

• JWT/Session은 서비스의 비즈니스에 따라, 구분될 것으로 보인다.
  JWT : 서버부담최소화, Scale-out시 용이한 장점으로 대표적으로 사용된다.
  Session : 동시접속제한과 같은 기능이 필요할 경우 사용 (대표적으로 넷플릭스 공유계정제한)
  

• OAuth 2.0 : 사용자의 편의, 내가 직접 로그인을 구현하지 않아도 되는 점, 개인민감정보를 가지고 있지 않는 점
  다양한 장점을 가지고 있어 주로 사용되지만, 로그인기능의 마비를 대비하여 2nd기능으로 많이 사용되고 있는 것으로 보인다.
  

• "모투"서비스에서는 JWT + OAuth 2.0 기능을 사용하기로 탕탕!

참고사이트

• jwt vs session
• jwt vs session 2
• OAuth 2.0이란
• OAuth 2.0 대표취약점과 보안 고려사항