🔒사용자 인증 방식 - Cookie/Session, JWT, OAuth

1) 쿠키/세션

• 쿠키는 사용자가 삭제하지 않는 이상 계속 남아있으며, 방문자의 정보를 방문자 컴퓨터의 메모리(클라이언트) 에 저장하는 것을 의미한다.
• 세션은 방문자의 요청에 따른 정보를 클라이언트가 아닌 웹 서버가 세션 아이디 파일을 만들어 서비스가 돌아가고 있는 서버에 저장하는 것을 의미한다.
• 세션 기반 인증 방식은 클라이언트의 상태를 서버에서 계속 유지하는 stateful 서버이다.
• 인증을 요구하는 서비스
  • 로그인 / 회원가입
    • 서버로 로그인 시도를 할때 id/pw를 보낸다.
    • db가 id/pw가 맞는지 검증하게 될 것임.
    • 세션 아이디 라는 것을 발급한다. 이 아이디를 가지고 통신할 예정.
    • 세션 아이디를 db에 저장하고, 이를 전송하면 클라이언트의 저장소인 쿠키에 세션 id를 저장해둔다.
    • 추후에 이 세션 아이디를 가지고 db에서 검증하게됨.
• 쿠키/세션 인증방식의 문제점
  • 보안에 취약함, 세션 id를 db에 저장하게 되는데→이는 과부하의 문제가 일어날 수 있다.
  • 또한 세션을 사용하면 더 많은 트래픽을 감당하기 위한 서버의 확장이 어려워진다.
  • 멀티 디바이스 환경에서 중복 로그인 처리가 되지 않는등 많은 문제를 가지고 있다.

 

2) JWT 인증 방식 = Json Web Token

• JWT란 JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 claim 기반의 웹 토큰이다.
• 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다.
• 요즘 많이 사용하는 기술로, 모바일 어플리케이션에 적합해 대부분이 JWT 인증 방식을 사용한다.
• 토큰 기반 시스템은 Stateless하며, 더이상 유저의 인증 정보를 서버나 세션에 담아두지 않는다. 따라서 유저들의 로그인 여부를 확인할 필요가 없어 서버를 손쉽게 확장할 수 있다.

 

• header/payload/signature로 구성되어있으며, JSON 형태인 각 부분은 일정한 알고리즘에 따라 인코딩된다. 
  • header- typ, alg로 구성되어있음.
    • typ: 토큰 type
    • alg: 사용 알고리즘 (SHA256) 명시
  • payload - 진짜 데이터가 들어가 있는 곳 (userIdx, name...) → 이 데이터 조각을 claim이라고 한다. (claim 기반의 웹토큰)
    •  등록된 클레임 : 토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터들로, key는 모두 길이 3의 string으로 이루어져 있다. 
      • iss : 토큰 발급자 (issuer)
      • sub : 토큰 제목 (subject)
      • exp: 토큰 만료 시간
      • nbf : 토큰 활성 날짜 (not before)
      • iat: 발급 일자 계산 부분 - 유효기간 계산하기 위해서 사용한다. EX) 30분이면 jwt 무효화.
      • jti : JWT 토큰 식별자, 중복 방지를 위해 사용 (JWT id)
    • 공개 클레임 : 사용자 정의 클레임으로, 공개용 정보를 위해 사용된다.
    • 비공개 클레임: 역시 사용자 정의 클레임으로, 서버와 클라이언트 사이에 임의로 지정한 정보를 저장한다.
  • signature - 헤더와 페이로드 부분을 암호화시킨다. (HS256, 서버 설정 암호화 알고리즘 등을 같이 혼합해서 사용.)

 

• 클라이언트 - 서버 통신 과정
  • 첫 로그인 시도 이후 DB 검증이후 JWT 토큰을 만들어냄.
    • 회원 가입 시에 비밀번호를 암호화시켜서 db에 저장함.
    • 로그인 시에 db에 저장된 비밀번호를 복호화하고, request로 들어온 비밀번호와 비교해서 로그인 검증 처리를 함.
  • 클라이언트에게 이 토큰을 전송하게 됨.
  • 그 이후로 계속 request시에 토큰을 헤더에 덧붙여서 보내면 서버에서 이 토큰을 검증 후 응답을 보낸다.

 

3) 소셜 로그인 - OAuth

• 오픈된 인증방식으로, 다른 서비스의 회원 정보를 안전하게 사용하기 위한 방법이다.
• 즉, 고객이 다른 서비스의 id/pw를 알려주지 않아도, 그곳에 저장된 고객의 정보를 우리 서비스에서 안전하게 사용하기 위해서 사용된다고 보면 됨.
• jwt나 쿠키/세션과 혼용해서 사용함.
• 제 3자 인증 방식
  • 고객이 우리 사이트에서 구글에 로그인을 했다. 
  •  구글은 고객이 구글 회원임을 확인하고,이 정보를 토대로 내 서버에게 access-token을 발급함
    • access-token을 해당 서버마다 다르게 사용함.
    • OAuth의 핵심인 access token은 임의의 문자열 값으로, 이 문자열의 정체는 이 토큰을 발급한 서비스만 알수 있다. 
    • 따라서 Access token의 존재 자체가 고객이 정보를 넘겨주는 것을 동의한다고 보는 것이다.
  • 그리고, 구글이 우리 서버로 고객을 리다이렉트해주면서 query string을 통해 access token을 넘겨주면 우리또한 access token을 쉽게 받아올 수 있다.
    • 리다이렉트는 redirect_uri를 정해 네이버/구글에 사전에 등록해놔야 사용할 수 있다.
    • 해당 redirect_uri 등록 절차를 거치지 않으면 악의적인 사용자가 redirect_uri값을 바꿔 값을 탈취할수도 있다. 따라서 반드시 사전 인증 절차를 거쳐야 한다.
  • 마지막으로, 해당 서드파티(네이버, 구글..)에서 요구하는 대로 구현해 access token을 전달하면, 사용자의 정보를 내 서버로 받아올수 있게 되는 것이다.

 

 

🙏 참고자료

https://velog.io/@sa1341/JWT-%ED%86%A0%ED%81%B0-%EC%9D%B8%EC%A6%9D

JWT 토큰 인증

https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

OAuth 란 무엇일까 · Showerbugs