본문 바로가기

TIL

231025 TIL

  • 오늘 공부한 것

http 메시지의 구조 
-header: 요청에 대한 정보들 + 인증 수단
-공백 : 헤더와 바디를 구분
-body : 서버로 보내야할 데이터

 

 

1)Session / Cookie ||| Session은 서버에서 가지고 있는 정보/Cookie는 사용자에게 발급된 세션을 열기 위한 열쇠(SESSION ID).

(only cookie : 클라이언트가 인증 정보를 책임, 보안성 취약 -> 장바구니 자동로그인설정 기능에 유용하게 쓰인다.)

세션 저장소를 필요(ex:Redis 4주 프젝에서 활용 중)
->로그인시 사용자 정보를 저장하고 열쇠가 되는 세션ID값 생성
->HTTP 헤더에 실어 클라이언트에 전송
->클라는 쿠키를 보관하고 있다가 인증이 필요한 요청에 쿠키(세션ID)를 넣어
보냄
-> 웹 서버에서는 세션 저장소에서 쿠키(세션ID)를 받고 저장되어 있는 정보와 매칭 후 인증완료.

Session / Cookie

1. 사용자가 로그인을 한다.

2. 서버에서는 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장한 후, 이와 연결되는 세션ID를 발행 

3 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냄

4. 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져옴

5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보냄

 

 

 

2)JWT |||  Access Token(JWT)을 HTTP 헤더에 실어 서버로전송(이 부분은 세션/쿠키 방식과 유사)

 

토큰의 구조 :
 - Header : 이 세가지 정보를 암호화할 방식(alg), 타입(type) 등(암호화X)

 - Payload : 서버에서 보낼 데이터.(유저의 고유 ID값, 유효기간)(암호화X)
 - Verify Signature :  Base64 방식으로 인코딩한(Binary Data를 Text로 변경하는 Encoding) Header,payload 그리고 SECRET KEY를 더한 후 서명 (암호화)

structure of JWT(Encoded Header + "." + Encoded Payload + "." + Verify Signature)////JWT FLOW

1. 사용자가 로그인 

2. 서버에서는 계정정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 삽입

3. JWT 토큰의 유효기간을 설정

4. 암호화할 SECRET KEY를 이용해 ACCESS TOKEN을 발급

5. 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 전송

6. 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인

7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져옴

 

 

세션/쿠키와 JWT의 차이점 :
세션/쿠키 = 세션 저장소에 유저의 정보를 넣는다 (저장소 필요)// JWT =  토큰 안에 유저의 정보들을 넣는다 + 암호화 (저장소 필요X)

'TIL' 카테고리의 다른 글

serviceworker  (0) 2024.02.29
231019 TIL  (0) 2023.10.20
231001 TIL  (0) 2023.10.01
TIL 230922  (0) 2023.09.23
TIL 230920  (0) 2023.09.20