[D+132] Final Project : 12일차 JWT(JSON Web Token) 학습

 

 

D+132

-  Final Project : 12일차 -

( multer, social login, jwt 학습 )

 

---

 

 

오늘은 내일부터 본격적으로 진행하게 될

소셜로그인과 multer, 그리고 토큰에 대해서 간단하게 학습을 하는 시간을 가졌다.

 

소셜로그인은 First 프로젝트 때 깃허브를 구현해 보았기도 했고,

같이 진행하는 페어분께서 First 프로젝트때 소셜로그인파트로 카카오를 이미 진행해 보셨다고 하셔서

큰 걱정은 없지만...(?)

이미지를 업로드하는 multer와 인증시 사용하는 JWT토큰에 대해서는

혼자 제대로 해본 적이 없어서 약간 긴장상태다.

 

multer는 단순히 내가 만든 서버에서 지정한 폴더에 이미지를 업로드하는 방법도 있지만

이 방법은 서버가 무거워지면서 부담을 가지게 되기 때문에

보통 배포시에 만드는 S3 버킷에서 저장될 수 있도록 구현한다고 하는데

난생 처음 들어보는거라 완전 제로베이스라서 약간 걱정이 되는것 같다.

 

그리고 JWT는 이전에 수업에서도 배우기도 했고, First 프로젝트에서도 사용해 본 적이 있지만

수업에서는 개념을 위주로 이해하려고 하다보니 실습을 제대로 이해하지 못한 채 넘어갔었고,

프로젝트때에는 팀장님이 인증구현을 맡으시고 나는 거의 관람객 수준이었어서 많이 미숙하다.

 

과연 무탈하게 잘 할 수 있을지 걱정이 되지만.... 미래의 나야 잘해줘...😅😅😅

 

 

---

⚠️ multer와 social login은 따로 작성해 볼 예정 입니다 ⚠️

 

 

JWT (jsonwebtoken)

 

세션(session) 원리

JWT를 알기전에 session이 어떤 원리로 작동하는 지에 대해 잠깐 살펴보자면,

 

① 먼저 회원이 로그인을 시도한다.

 

② 유저가 서버로 부터 로그인을 요청하면 서버는 그 순간 세션을 생성하고 유저에게 sessionID를 부여한다.

 

③ 이 이후부터 유저는 로그인을 한 회원만 접근 할 수 있는 요청을 할 경우에,

서버에게 로그인요청을 했을 때 받았던 sessionID를 요청과 함께 보내준게 된다.

 

④이때 서버는 유저에게 받은 sessionID를 통해서 우리 회원이 맞는지 확인하고,

일치할 경우 요청에 따른 응답을 보내주게 된다.

 

이런 원리로 작동하게 되는데 세션나름의 장점도 있겠지만 이렇게 될 경우에

서버에서 세션을 만들기 때문에 회원이 많아질수록 서버에서 차지하는 데이터의 양이 많아져

서버에 부담이 생길 것이다.

 

JWT(jsonwebtoken) 원리

세션의 이러한 단점으로 보완된 것이 바로 토큰이다.

 

JWT는 많은 토큰들 중의 하나로 가장 보편적으로 사용되고 있는 아이이다.

 

① 회원이 로그인을 한다.

 

② 서버는 JWT를 통해서 토큰을 생성하고 생성된 토큰을 회원에게 전송해준다,

 

③ 서버로부터 받은 토큰을 클라이언트는 보관하게 된다.

(이때 저장방식은 Local Storage, cookie 등 다양하다)

 

④ 이 이후에 회원은 로그인을 한 회원만 접근할 수 있는요청을 할 경우에,

서버에게 로그인요청을 했을때 받았던 토큰을 Header에 저장해 토큰을 전달한다.

 

⑤ 서버는 회원으로부터 받은 토큰을 통해 직접 만든 토큰이 맞는 지 확인을 한 후에,

획인되었을 경우 요청에 따른 응답을 전송해 준다.

 

인증방식에서 세션과 토큰의 가장 큰 차이점은

세션은 서버가 세션을 가지고있고 클라이언트에게 ID를 부여한다면,

토큰은 클라이언트자체에 토큰을 부여하는 방식으로 서버에 용량부담이 훨씬 적다.

 

JWT(jsonwebtoken)의 구조

☝🏻 헤더 (header)

• alg : 어떤 알고리즘으로 암호화 할거야?

• typ : 어떤 타입의 토큰이야?

 

✌🏻 내용 (payload)

•토큰에서 사용할 정보의 조각이 담겨있다.

• 내가 정볼르 추가할 수도 있다.

• 페이로드엔 값이 많이 들어갈수록 데이터의 양이 증가하기 때문에 최소한의 값을 넣어주는 것이 좋다.

• 오픈된 구역으로 공개되면 안되는 정보를 넣어서는 안된다.

•id(id 정보), name(name 정보), exp(기한) 등 다양한 정보들이 들어갈 수 있다.

 

🤟🏻 서명 (signature)

• 헤더와 내용을 암호환 값으로 secrete key가 추가되어 암호화가 되었다고 보면 된다.

 

Access token / Refresh token

• Access token : 사용자의 권한을 얻을 때 사용되며, 인증하는 절차에서 핵심을 사용되는 토큰이다.

• Refresh token : Access token이 생성될때 동시에 생성되며, Access token보다 긴 유효기간을 주고 생성되며,

Access token이 만료될 경우에 갱신을 하기 위한 목적으로 사용되며, Refresh token은 필수로 만들어야 되는 것은 아니다.

 

메소드

• sign : 토큰 생성하기 

sign( ) { _____ , _____ , _____ , _____ } 

1st 인자 - 페이로드
2nd 인자 - 비밀키 (비밀키는 누구에게도 보여져서는 안된다)
3rd 인자 - 토큰 정보 (ex. 유효기간)
4th 인자 - 콜백함수 (생략가능하며, 없을 시에 동기처리)

 

• verify : 권한 확인하기

  - jsonwebtoken 모듈 권한을 확인하는 메서드

  - 반복적으로 작성하는것을 피하기 위해 보통 미들웨어로 잘 사용된다.

verify( ) { _____ , _____ }

1st 인자 - token (인증이 된 토큰인지 확인하는 용도)
2nd 인자 - secret key (암호화 된것을 디코딩 하는 용도)