1 - 4. 네트워크 기초

로그인, 쿠키와 세션, JWT 토큰

HTTP란?

stateless 하다. 연결을 끊는 순간 사용자와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.

브라우저에서 상태를 유지하는 방법

• 쿠키와 세션
• 토큰 기반 방식

세션

서버와 클라이언트의 연결이 활성화된 상태

 

세션 ID

웹 서버 메모리에 저장되는 클라이언트에 대한 유니크한 ID(서버 또는 데이터베이스에 저장)

 

쿠키

• 키 - 값으로 구성된 작은 데이터 조각
• 쿠키에 담긴 데이터는 브라우저에서 관리된다. 하지만 보통 만료 날짜를 서버에서 설정한다.
• 이름, 값, 만료 날짜 등으로 구성

쿠키와 세션

1. 처음 로그인 -> 쿠키, 세션 ID 생성 그 이후 다시 요청했을 때 HTTP 헤더에 쿠키를 포함시켜 요청한다.
2. 해당 쿠키에 맞는 세션 ID로 전에 로그인했던 아이디인지 확인
3. 로그인을 유지

XSS(Cross Site Scripting)

쿠키는 클라이언트에서 자바스크립트로 조회가 가능하다. 공격자들이 자바스크립트로 쿠키를 가로채고자 시도를 하는데 이를 XSS라고 한다.

해결 방법 : HTTP Only Cookie 또는 secure cookie를 사용한다.

• Set-Cookie : 쿠키명 = 쿠키값; path=/ ; secure
• Set-Cookie : 쿠키명 = 쿠키값; path=/ ; HttpOnly

보통은 HTTP 관련 라이브러리에 적혀있는 대로 사용한다.

ex) axios.defaults.withCredentials = true;

 

쿠키 - 세션 방식의 단점

로그인할 때마다 세션 ID를 저장해야 돼서 로그인 중인 유저의 수가 늘어난다면 서버의 메모리 과부하 등 악영향을 미친다. 

 

토큰 기반 인증 방식

JWT토큰 인증은 토큰 기반 인증서버를 통해서 하게 하고 서버는 stateless 하게 내버려 두자. 요청 -> 토큰 생성 -> 이후 사용자가 토큰을 헤더(authoriztion 키에 넣어서 요청, 이 토큰을 기반으로)

JWT(JSON Web Token, RFC 7519)

헤더, 페이로드, 서명으로 이루어져 있으며 JSON 객체로 인코딩 된다. 메세지 인증, 암호화에 사용

 

Header

어떠한 방법의 서명 알고리즘을 사용할 것인가에 대한 정보

Payload

데이터, 토큰 발급자, 토큰 유효기간(인증이 필요한 최소한의 정보만)

Signature

헤더에 정의된 알고리즘으로 인코딩된 헤더와 페이로드를 합친 값, 그리고 비밀키를 기반으로 생성된 서명 값

 

JWT 장점

사용자가 인증되면 사용자는 모든 시스템에서 사용할 수 있는 보안 토큰을 받습니다. 즉, 단일 엔드포인트를 생성해서 다른 모든 서버 간의 API 상호작용을 인증할 수 있다는 점에서 좋다.

 

JWT의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없다.

확장성, 디버깅, 사이즈가 작음, JWT토큰 자체가 독립적이다.

 

JWT 단점

더 많은 필드가 추가되면 토큰이 비대해져 트래픽에 영향

탈취하여 디코딩하면 데이터를 볼 수 있다.

 

브라우저 렌더링 과정

1. DOM 트리 구축

하나의 html 페이지는 div, span 등 각각의 요소를 가진다. 각 요소는 하나하나 노드로 설정이 되어 트리 형태로 저장된다. 이를 DOM 트리라고 한다. 예를 들어 div > span, span이 있다면 div라는 부모 노드 밑에 span이라는 자식 노드가 2개 생기는 것이다.

2. 렌더 트리와 렌더 레이어 생성

각각의 노드는 CSS파서에 의해 정해진 스타일 규칙이 적용되어 있다. span.color="red"는 노드 색깔이 빨간색이다 등을 말한다. 이런 규칙에 따라 CSSOM이라는 트리가 만들어지고 미리 만들어놓은 DOM트리 내에 있는 노드와 함께 렌더 객체가 생성되며 이들이 모여 병렬적인 렌더 트리가 생성된다. 상속적인 스타일은 부모 노드에만 위치하도록 설계하는 등의 최적화를 거쳐 렌더 레이어가 완성된다.

3. 렌더 레이어를 대상으로 Layout설정

이때 좌표는 보통 부모를 기준으로 설정된다. Global Layout은 브라우저 사이즈가 증가하거나 폰트 사이즈가 커지면 변경된다.

4. 렌더레이어를 대상으로 칠하기

픽셀마다 점을 찍듯 칠한다. 이를 레스터화라고도 한다.

5. 레이어 합치기 및 표기

각각의 레이어로부터 비트맵이 생성되고 GPU에 텍스처로 업로드된다. 그다음 택스처들은 서로 합쳐져 하나의 이미지로 렌더링 되며 화면으로 출력된다.

 

웹 브라우저의 캐시

대표적인 캐시로는 웹 브라우저의 작은 저장소 쿠키, 로컬 스토리지, 세션 스토리지가 있다. 이러한 것들은 보통 사용자의 커스텀한 정보나 인증 모듈 관련 사항들을 웹 브라우저에 저장해서 추후 서버에 요청할 때 자신을 나타내는 아이덴티티나 중복 요청 방지를 위해 쓰인다.

 

쿠키

쿠키는 만료기한이 있는 키 - 값 저장소이다. same site 옵션을 strict로 설정하지 않았을 경우 다른 도메인에서 요청했을 때 자동 전송되며, 4KB까지 데이터를 저장할 수 있고 만료기한을 정할 수 있다. 쿠키를 설정할 때는 document.cookie로 쿠키를 볼 수 없게 httponly 옵션을 거는 것이 중요하며, 클라이언트 또는 서버에서 만료기한 등을 정할 수 있는데 보통 서버에서 만료기한을 정한다.

 

로컬 스토리지

로컬 스토리지는 만료기한이 없는 키 - 값 저장소이다. 10MB까지 저장할 수 있으며 웹브라우저를 닫아도 유지되고 도메인 단위로 저장, 생성된다. 클라이언트에서만 수정 가능하다.

 

세션 스토리지

세션 스토리지는 만료기한이 없는 키 - 값 저장소이다. 탭 단위로 세션 스토리지를 생성하며, 탭을 닫을 때 해당 데이터가 삭제된다. 5MB까지 저장이 가능하다. 클라이언트에서만 수정 가능하다.

 

HTTP의 상태 코드

1xx(정보)

요청을 받았으며 프로세스를 계속한다.

 

2xx(성공)

요청을 성공적으로 받았으며 인식했고 수용한다.

• 200 OK : 요청을 성공적으로 되었습니다.
• 201 Created : 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었다.

3xx(리다이렉션)

요청 완료를 위해 추가 작업 조치가 필요하다

• 301 Moved perma nently : 이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미한다. 변경된 새로운 URI를 응답에서 주는 것이 좋다.

4xx(클라이언트 오류)

요청의 문법이 잘못되었거나 요청을 처리할 수 없다.

• 400 Bad Request : 이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미한다.
• 401 Unauthorized : 클라이언트의 인증이 되지 않음을 의미한다.

5xx(서버 오류)

서버가 명백히 유효한 요청에 대해 충족을 실패했다.

• 500 Internal Server Error : 서버에 오류가 있음을 의미한다.

HTTP의 메서드

POST : 자원을 생성

보통 하위 자원을 생성한다. 성공적으로 생성되면 HTTP 상태 201을 반환

GET : 읽기

성공 시 200, 오류의 경우 가장 자주 404(Not Found) 또는 400(Bad Request)을 반환한다. 데이터를 수정, 삭제하는데 반드시 사용하면 안 된다.

PUT : 업데이트(전체 자원)

요청을 보낼 때 전체를 보내야 한다.

PATCH : 업데이트(일부 자원)

요청을 보낼 때 수정하는 일부분을 보내야 한다.

DELETE : 삭제

 

REST API

API란?

API는 소프트웨어와 소프트웨어 사이 데이터 전송을 가능하게 하는 프로그램이다.

 

Uniform-Interface

자원들이 각각의 독립적인 인터페이스를 가져야 한다.

• 웹페이지를 변경했다고 웹 브라우저를 업데이트하는 일은 없어야 된다.
• HTTP 명세나 HTML 명세가 변경되어도 웹페이지는 잘 작동해야 한다.

REST API 아키텍처 규칙

1. Self - descriptive messages

HTTP Header에 타입을 명시하고 각 메시지(자원)들은 MIME types에 맞춰 표현되어야 한다.

예를 들어. json을 반환한다면 application/json으로 명시해주어야 한다. MIME types는 문서, 파일 등의 특성과 형식을 나타내는 표준이다. 'font/ttf', 'text/plain', 'text/csv' 등

 

2. HATEOAS 구조

하이퍼링크에 따라 다른 페이지를 보여줘야 하며 데이터마다 어떤 URL에서 원했는지 명시해주어야 한다.

 

3. Stateless

이 규칙은 HTTP 자체가 Stateless이기 때문에 HTTP를 이용하는 것만으로도 만족된다. 즉 REST API를 제공해주는 서버는 세션(session)을 해당 서버 쪽에 유지하지 않는다는 의미이다.

 

4. Cacheable

HTTP는 원래 캐싱이 된다. 새로고침을 하면 304가 뜨면서 원래 있던 js와 css이미지 등을 불러오는 것을 볼 수 있다. 이러한 캐싱은 네트워크 요청을 줄여주며 이는 UX 향상에도 도움이 된다. 네트워크 요청 시 해당되는 자원들을 복사해서 메모리에 저장해두었다가 또 같은 요청 시 네트워크 요청을 하지 않고 브라우저 메모리에 있던 자원을 다시 반환한다. HTTP 메서드 중 GET에 한정되며 Cache-Control:max-age=100(100초) 이런 식으로 한정된 시간을 정할 수가 있다. 캐싱된 데이터가 유효한지 판단하기 위해 Last-modifed와 Etag를 쓴다. Etag는 전달되는 값에 태그를 붙여서 캐싱되는 자원인지를 확인해주는 것이다.

 

5. Client-Server 구조

클라이언트와 서버가 서로 독립적인 구조를 가져야 한다. 물론 이는 HTTP를 통해 가능한 구조이다. 서버에서 HTTP 표준만 지킨다면 웹에서는 그에 따른 화면이 잘 나타나게 된다. 서버는 API를 제공하고 그 API에 맞는 비즈니스 로직을 처리하면 된다. 클라이언트에서는 HTTP로 받는 로직만 잘 처리하면 된다.

 

6. Layered System

계층구조로 아키텍처를 만들 수 있다는 것을 뜻한다.

 

URI 규칙

1. 동작은 HTTP 메서드로 해야 한다. 수정 = put, 삭제 = delete, 추가 = post, 조회 = get을 이용해야 한다. 예를 들어 /books/delete/1 이렇게 표기하면 안 된다.
2. 확장자는 표기하지 말아야 한다.
3. 동사가 아닌 명사로만 표기해야 한다. 유저가 책을 소유한다라고 하려면 유저/유저아이디/inclusion/책/책 아이디
4. URI는 계층적인 내용을 담고 있다. /집/아파트/전세 이런 식으로 내려가야 한다.
5. 소문자로 쓰며 너무 길 경우에는 *****-**** 를 쓴다.
6. HTTP 응답 상태 코드를 활용한다.

도서관 시스템의 REST API 예시

get('/books/') : 모든 책을 조회한다.

post('/books/booksid') : 책을 생성한다.

put('/books/'booksid) : 책을 수정한다.

get('/books/booksid') : 특정 책을 조회한다.

put('/users/userid/books/booksid') : 어떤 유저가 특정 책을 빌린다.

patch('/users/userid/books/booksid') : 어떤 유저가 특정 책을 빌린다.