3주차_210712) GET&POST, 로그인 구현 방법(쿠키, 세션, JWT)

1. CRUD란?

- CRUD는 컴퓨터 SW가 갖는 기본 데이터 처리 기능(Create, Read, Update, Delete)

 

2. GET & POST

GET	Read
POST	Create
UPDATE(PUT, PATCH)	Update
DELETE	Delete

1) Get

• 서버로부터 정보 읽어오기(Ex. 게시판 검색, 조회)
• 요청 전송시, 필요 데이터를 Body가 아닌 파라미터로 전송(링크에 보임) 
• url 길이 제한이 있어 파라미터 전송 제약
• URL 끝 ?뒤에 key-value쌍(요청한 파라미터)가 &로 연결된 형태 
• 파라미터는 url에 그대로 노출됨 -> 노출되지 않아야 할 정보는 GET방식 사용하면X(ex. 로그인)
• 언제나 url은 동일한 결과 리턴(같은 url 요청시, 결과는 같아야 함)
• Ex. 네이버에 '안녕'을 검색했을 때 url -> https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=1&ie=utf8&query=%EC%95%88%EB%85%95

2) POST

• 서버에 정보 생성하기(Ex. 게시판 작성, 회원가입, 로그인)
• 전송해야할 데이터를 HTTP 메시지 Body에 담아 전송(보이지 않음)
• Body 길이 제한이 없이 대용량 데이터 전송O
• 같은 요청에도 결과는 Body 내용에 따라 달라짐
• 로그인은 Read기능을 하지만 Body에 담아 id, password를 감춰야하기 때문에 예외적으로 POST방식을 사용

※ GET, POST는 무조건적인 프로토콜은 아니다!! (로그인과 같은 경우, 상황에 따라 Read기능을 하지만 POST방식을 사용할 수도 있음)

• 프로토콜: 컴퓨터들 간의 원활한 통신을 위해 지키기로 약속한 규약(지키지 않았을 때 문제가 생김)

3) UPDATE PUT: 전체 수정

• PATCH: 부분 수정

3. 로그인이란?

- 사용자가 누구인지 특정하는 것

 

4. HTTP(TCP) 특징

• Connectionless(비연결성): 클라이언트와 서버가 한 번 연결을 맺은 후 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버림(클라이언트, 서버 간 연결 유지X) 
• Stateless(비상태성): Connectionless로 인해 서버는 클라이언트를 식별할 수가 없음
• 서버가 클라이언트에게 받은 요청을 응답결과로 만들어 응답을 하고난 후 바로 클라이언트와의 연결을 끊음 → 동일한 클라이언트가 요청할 때 마다(접속, 게시글 보기, 게시글 작성 등) 매번 새롭게 인증해야함 → 이러한 단점을 해결하기 위해 HTTP의 비연결성과 비상태성을 보완하여 서버가 클라이언트를 식별하게 해주는 "쿠키 & 세션" 개념이 등장
  

5. 로그인 구현

1) 쿠키

• 쿠키는 웹 사이트에 접속시 생성되는 정보를 담은 임시 파일(삭제하지 않으면 유지됨)
• 쿠키는 서버가 사용자의 웹 브라우저에 저장하는 데이터(브라우저마다 쿠키가 다름 →  브라우저가 다르면 서버에서는 다른 사용자로 인식)
• 쿠키의 데이터 형태는 Key, Value 쌍(ex. user: "hsy"), String 형태
• 로그인 시, 사용자를 특정할 수 있는 정보들을 쿠키(웹 브라우저)에 저장하고 사용자 요청시, 서버에 쿠키를 함께 보내 서버가 사용자를 식별하게 함
• 쿠키는 서버가 가지고 있는 것이 아니라 사용자에게 저장되기 때문에 말단 해킹(클라이언트 단에서 임의로 고치거나 지울 수 있고 가로채기도 쉬움)가능성때문에 보안이 취약함(쿠키에 민감하거나 중요한 정보를 담는 것은 위험) → 세션 개념 등장
  

2) 세션

• 서버에서 클라이언트 연결을 직접 관리
• 세션 아이디는 웹 브라우저 당 1개씩 생성되어 웹 컨테이너에 저장되며 브라우저 종료시 소멸됨
• 로그인한 사용자에 대해서만 세션을 생성하는 것이 아니라 로그아웃하면 새로운 사용자로 인식해서 새로운 세션이 생성
• 서버단에 사용자 정보 저장하는 구조 → 서버의 메모리를 차지, 서버 과부화의 원인
• 사용자 단말기기(핸드폰, 태블릿 등)이 다양화로 브라우저에서 실행하지 않는 경우 쿠키, 세션 사용이 불가능해짐 →  토큰 방식 개념 등장
• 세션 정보는 파일에 저장됨
• 웹서버(nginx) + WAS(톰캣/php) 형태일 때 세션 사용O(웹 서버만으로는 세션 사용X)
• Spring Security => 내부적으로 쿠키/세션을 사용합니다. Spring Security + JWT => 쿠키/세션 사용안함

※쿠키와 세션은 브라우저에서만 사용가능한 기술이다!! 

 

3) 토큰 방식(JWT: Json Web Token)

• 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술
• 클라이언트의 세션 상태를 저장하는 게 아니라 필요한 정보를 토큰 body에 저장해 클라이언트가 가지고 있고 그것을 증명서처럼 사용
  
• 리액트에서 localStorage, sessionStorage 토큰 저장

<인코딩과 디코딩>

• Encode: 문자열을 특정 규칙에 의거해 컴퓨터가 이해할 수 있는 형태(byte)로 변환하는 것
• Decode: 특정 규칙에 의거해 변환된 byte를 원본 문자열로 변환하는 것

※인코딩과 디코딩의 목적: 국가별 언어가 다양(아랍어, 중국어, 한국어 등) → 인터넷 상에서 모든 언어를 제약없이 사용하기 위해 모두 영어로 변환(실제로 네이버에 "안녕을 검색하면 url 끝에 "안녕"이라고 보이지만 이것은 브라우저에서 지원하는 기능일 뿐, 실제 url을 복사해보면 https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=1&ie=utf8&query=%EC%95%88%EB%85%95 과 같은 모두 영어로 이루어진 형태)

 

<암호화와 복호화>

• 암호화: 데이터를 비밀로 유지하려는 의도로 데이터를 변환하는 것. 
  • 단방향 암호화: 복호화 X(원본 알 수X)
    • 결과값이 고정되어 있는 형태(sha-256): input 길이와 상관없이 result 길이 동일(==으로 비교 O), 한글자만 달라도 결과값이 아예 달라짐
    • 결과값이 유동적인 형태(bcrypt): true/false로 반환하여 result가 input으로 부터 파생된 것인지 알 수 있음(==으로 비교 X)
  • 양방향 암호화: 복호화 O(키를 이용)
• 복호화: 특수 키(대칭키, 공개키)를 사용하여 암호를 해독하는 것

※암호화와 복호화의 목적: 데이터를 비밀로 유지하기 위함

 

<단방향 암호화와 로그인>

• 2중 암호화
  
  • Client가 1차 비밀번호 암호화하여 전송
  • Server가 2차 단방향 암호화 후 저장 

 

 

[참고]

https://victorydntmd.tistory.com/286

[HTTP] HTTP 특성(비연결성, 무상태)과 구성요소 그리고 Restful API

 

https://devuna.tistory.com/23

[web] 쿠키(cookie)와 세션(session)의 개념/차이/용도/작동방식