[컴퓨터네트워크] REST API란? Cookie, Session, Token 기반 인증

Q. REST API에 대해 설명해주세요.

- REST? 

Representational State Transfer의 약자로 웹 서비스를 만들기 위한 일련의 아키텍처 원칙입니다. 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다.

REST는 다음과 같은 3가지로 구성됩니다. 

• 자원(resource) - URI
  해당 소프트웨어가 관리하는 모든 것 ex) 문서, 그림, 데이터 등
  모든 자원은 고유의 URI(URL)을 가지며 클라이언트는 이 URI를 지정하여 해당 자원에 대해 CRUD 명령을 수행할 수 있다.
• 행위(verb) - HTTP method
  클라이언트가 HTTP Method(GET, POST, PUT, DELETE)를 이용하여 자원을 조작하는 것
• 표현(Representations)
  서버의 행위(verb)에 대한 응답(Json, XML을 통해 데이터를 주고 받는 것이 일반적)

CRUD Operation
- Create : 생성(POST)
- Read : 조회(GET)
- Update : 수정(PUT)
- Delete : 삭제(DELETE)

REST의 특징
1. Server-Client(서버-클라이언트 구조)
2. Stateless(무상태)
3. Cacheable(캐시 처리 가능)
4. Layered System(계층화)
5. Uniform Interface(인터페이스 일관성)

- REST API란?

REST한 API를 REST API, RESTful API라고 부릅니다.

두 개의 컴퓨터가 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스입니다. 

- REST API의 사용 이유 (장점)

1. 쉬운 사용성

REST API의 메시지를 읽는 것 만으로 메시지의 의도를 확실히 파악할 수 있습니다.
또한 HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다.

2. 서버와 클라이언트의 역할을 명확하게 분리 
RESTful API는 무상태로 설계되기 때문에, 클라이언트에서 서버로의 각 요청은 이전 요청의 컨텍스트에 의존하지 않습니다. 즉, 서버는 클라이언트의 이전 요청의 컨텍스트를 유지할 필요가 없습니다. 

따라서 클라이언트와 서버가 독립적으로 발전하고 각자의 역할이 명확하게 나뉘게 됩니다.

---

Q. Cookie, Session, Token 기반 인증?

기존의 HTTP 프로토콜 인증 방식은 Stateless이기 때문에, 로그인 후 다시 웹 페이지에 접근하면 로그인 상태가 유지되지 않는다는 문제점이 있었습니다. 이러한 HTTP 프로토콜의 인증 문제를 해결하기 위해 사용하는 방법으로는 쿠키와 세션이 있습니다.

쿠키 기반 인증

정의

쿠키는 서버에서 발급된 세션을 열기 위한 키 값입니다.

서버는 클라이언트에 인증 정보를 담은 쿠키를 전송하고, 클라이언트는 전달받은 쿠키를 요청과 같이 전송하여 stateless한 인터넷 연결을 stateful하게 유지합니다.

서버가 클라이언트에 정보를 전달할 때 저장하고자 하는 정보를 응답 헤더(Cookie)에 저장하여 전달합니다.

동작

사용자가 웹 애플리케이션에 로그인하면 서버는 고유한 세션 식별자를 생성하여 서버 측에 저장합니다. 그런 다음 서버는 클라이언트의 브라우저에 저장되는 쿠키 형식으로 이 식별자를 클라이언트에 다시 보냅니다. 이 쿠키는 클라이언트에서 서버로의 모든 후속 요청과 함께 전송되어 서버가 사용자의 세션을 식별하고 각 요청에 대해 인증할 수 있도록 합니다.

장점

1. 구현이 용이
2. 확장성 : 서버는 클라이언트에 인정 정보를 담은 쿠키를 전송하고, 클라이언트는 전달받은 쿠키를 요청과 같이 전송하여 stateless한 인터넷 연결을 stateful하게 유지할 수 있습니다.
3. 유연성 : 쿠키 기반 인증은 다양한 응용 프로그램의 특정 요구 사항을 충족하도록 사용자 정의할 수 있으므로 개발자가 쿠키 만료 시간을 구성하거나 응용 프로그램의 다른 부분에 대해 다른 쿠키 이름을 사용할 수 있습니다.
4. 호환성 : 쿠키 기반 인증은 모든 주요 웹 브라우저와 호환되며 데스크톱 및 모바일 애플리케이션 모두에서 사용할 수 있습니다.

문제점

• Cookie가 노출되었을 때 ID, PW와 같은 중요정보들이 쉽게 노출됩니다.
• 웹 브라우저마다 Cookie에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능합니다.
• Cookie의 사이즈는 4KB로 제한되어 많은 양의 데이터를 담을 수 없습니다.

세션 기반 인증

정의 

클라이언트와 서버 간 연결이 활성화된 상태를 세션이 활성화되어 있다고 합니다. 쿠키는 클라이언트에 정보를 저장하지만, 세션은 데이터를 서버에 저장하고 쿠키에는 암호화된 세션ID만 저장합니다.

동작 

1. 클라이언트가 로그인을 한다.
2. ID/PW 로 인증 후 사용자를 식별할 세션 ID를 만들어 서버의 세션 저장소에 저장한다.
3. 세션 ID를 특정한 형태(Cookie or json)로 클라이언트에 다시 반환한다.
4. 이후 사용자 인증이 필요한 정보를 요청할 때마다 이 세션 ID를 쿠키에 담아 서버에 함께 전달한다.
5. 인증이 필요한 api일 때, 서버는 세션 ID가 세션 저장소에 있는지 확인한다.
6. 있다면 인증 완료 후 api 처리, 없다면 401 에러를 반환한다.

장점 

보안 : 클라이언트의 브라우저가 아닌 서버 측에 사용자의 자격 증명(세션 ID)이 저장되기 때문에 안전합니다.

문제점 

• 서버에 부하 : 서버에 세션을 저장하기 때문에 사용자 수가 많아지면 서버의 부담이 늘어납니다.
• 확장성이 나쁨 : 서버를 스케일 아웃할 경우, 여러 서버에 세션 정보를 복사해줘야 합니다. 
• stateful : 상태를 저장해야 하므로, 추가 저장소가 필요하고 HTTP의 Stateless한 특성을 위반합니다.
• 보안 : 세션 ID가 남긴 쿠키가 탈취될 경우 정보가 유출됩니다.

토큰 기반 인증

정의 

JWT (JSON Web Token) 는 인증에 필요한 정보들을 암호화시킨 토큰을 의미합니다. 위의 세션/쿠키 방식과 유사하게 사용자는 Access Token (JWT Token) 을 HTTP 헤더에 실어 서버에 전송합니다. 토큰은 임의로 생성된 비밀번호 같이 동작합니다. 제한된 수명을 가지고, 새로운 토큰은 한번 만료되면 새로 생성되어야 합니다.(Refresh Token)

동작 

1. 사용자가 로그인 합니다.
2. 서버는 요청이 들어오면 사용자를 검증하고 유효할 경우 Access Token을 클라이언트에 반환합니다.
3. 클라이언트는 토큰을 저장하고 인증이 필요한 요청마다 토큰을 header에 담아 서버에 전달합니다.
4. 서버는 토큰을 검증한 후 유효할 경우 클라이언트의 요청에 응답합니다.

장점 

1. 무상태(Stateless) : 서버 측에 세션 정보를 저장할 필요가 없으므로 서버에 부하가 적고 애플리케이션을 더 쉽게 확장하고 유지 관리할 수 있습니다.

2. 도메인 간 호환성 : 토큰은 헤더에 포함되어 있고 서버 측 스토리지 또는 데이터베이스 조회가 필요하지 않으므로 여러 도메인 또는 하위 도메인에서 사용할 수 있습니다.

3. 보안 : JWT는 비밀 키 또는 공개/개인 키 쌍으로 서명할 수 있으므로 사용자 인증 데이터를 안전하게 전송할 수 있습니다.

문제점 

• 토큰을 강제로 만료시킬 수 없습니다. 만약 토큰이 해킹당했다면 만료되기 전까지 해커는 서버에 요청을 보낼 수 있습니다.
  access token을 사용하는 기간동안은 stateless하지만, 만료되었을 때는 stateless가 깨지게 됩니다. 

 

참고 

REST API란 무엇인가? 왜 사용하는가?

[네트워크] REST API란? REST, RESTful이란?

 

Cookie, Session, Token 의 차이점

 

JWT란? JWT , Session, Cookie 비교

서버(Session/Cookie)기반 인증 방식과 JWT 토큰 기반 인증 방식의 차이

AUTHENTICATION - 쿠키기반/세션기반/토큰기반인증