스프링부트, REST, Token

※ Spring & Spring Boot

• 스프링부트는 스프링을 설정하고 사용하기 편하게 하기 위한 스프링 베스트 프랙티스를 모아놓은 스트링 래퍼
• 스프링의 특징: 범용, 경량급, 엔터프라이즈 기반 오픈소스 프레임워크

ㅁ 스프링 프레임워크의 특징

1) 컨테이너 역할

2) DI(Dependency Injection) 지원: Spring은 설정 파일이나 어노테이션을 통해 객체 간의 의존관계를 설정

3) AOP(Aspect Oriented Programming) 지원: 트랜잭션이나 로깅, 보안과 같이 공통적으로 필요로 하는 모듈들을 실제 핵심 모듈에서 분리해서 적용

4) POJO(Plain Old Java Object) 지원: 컨테이너에 저장되는 Java 객체는 특정한 인터페이스를 구현하거나, 특정 클래스를 상속받지 않아도 됨

5) 트랜잭션 처리를 위한 일관된 방법을 지원: 설정을 통해 정보를 관리

6) 영속성과 관련된 다양한 API지원: ORM(Object Relational Mapping) 프레임워크 연동 지원(MyBatis, Hibernate 등)

+ 톰캣이 내장되어 있어 단독으로 실행이 가능하고, xml 설정 파일이 필요 없음

 

ㅁ Maven

- 스프링의 의존 라이브러리를 간편하게 추가할 수 있도록 의존성 주입을 제공

- 프로젝트 구조를 자동으로 구성

- 빌드를 통해 배포를 위한 파일을 생성

 

ㅁ Spring Initializer

https://start.spring.io/

이용해서 프로젝트 생성 후 관리 가능!

 

---

※ REST

• HTTP를 사용한 웹 서비스 방식

ㅁ Background Information

- SOAP > XML / REST > JSON

- HTTP Methods

Method	Description
GET	자원 요청
POST	Entity를 포함한 자원 요청
HEAD	HTTP Header 정보만 수신
TRACE	Request의 루프백 테스트
PUT	URL에 자원을 생성
DELETE	URL의 자원을 삭제
OPTIONS	응답 가능한 HTTP 메소드를 요청
CONNECT	터널링의 목적으로 연결 요청(프록시에서 사용함)

 

ㅁ RESTful 기반 웹 서비스

- HTTP 프로토콜로 데이터를 전달하는 프레임워크

- 핵심은 웹에 개발된 리소스 이용

- REST API: 소유자의 자원에 접근할 수 있는 API

- REST 원리 및 원칙(제약조건)

  1) 확장성 있는 웹 서비스

  2) Client-Server: Client를 Server로부터 분리(Veiw와 Data를 분리)

  3) Stateless: 세션정보와 같은 Context를 저장할 필요가 없음(서버의 세션을 모두 제거) > 인증 방식도 변함(API Key 혹은 토큰)

  4) Cacheable

  5) Layered system(인접한 층끼리만 통신하기)

  6) Code on Demand

  7) Uniform interface

    -> Resource Identifier(URI)

    -> Resource Representations(Representation: 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보)

        클라이언트와 서버 간의 내용 협상(Content Negotiation)을 통해 내용이 정해짐. 사전 협상에 의해 서버가 Representaion을 선택.

    -> Self-Descriptive message & API

        Rest는 Stateless. 클라이언트 - 서버 간 충분한 메시지가 필요하다!

    -> HATEOAS(Hypermedia As Engine Of Application State)

---

※ 인증

ㅁ 종류

- 로그인 기반 인증(Credential-Based Authentication): 토큰기반 인증

- OAuth2(인증 정보를 다른 어플리케이션에서 가져옴, 제 3자가 인증을 처리): 카카오, 페이스북, 구글 등의 정보를 인용

- Two-Factor Authentication: 로그인 후에 한 번 더 인증하는 방식

- Hardware Authentication

 

ㅁ 서버 기반 인증 시스템 문제점

- 유저가 인증할 때 기록을 서버(메모리 혹은 DB 시스템)에 저장

- 유저의 수(동시 접속)가 많아지면 부하가 커짐

- 클러스터링 구성 시 세션 정보도 공유해야 하고, 서버 구성이 어려움

- CORS(Cross-Origin Resource Sharing): 쿠키를 여러 도메인에서 관리하는 것이 번거로움

 

ㅁ 토큰 기반 인증 시스템 작동 원리

1) 서버가 클라이언트에게 웹 사이트를 제공

2) 클라이언트에서 유저가 아이디/비밀번호로 로그인 수행

3) 서버측에서 해당 정보 검증

4) 정확하면 서버측에서 유저에게 signed token 발급

5) 클라이언트에서는 토큰을 저장해 두고 요청마다(읽기, 쓰기, 삭제 등의 동작) 토큰을 서버에 함께 전달

6) 서버에서 토큰을 검증하고 요청에 응답

(토큰은 HTTP 헤더에 포함시켜서 전달)

 

ㅁ 토큰 기반 인증 시스템의 장점

- 무상태(Stateless), 확장성(Scalability)

- 보안성: 쿠키를 사용하지 않음

- Extensibility: 기능 확장

- 여러 플랫폼 및 도메인에서 사용하며, 웹 표준 기반

 

ㅁ JSON Web Token

1) 웹표준, 다양한 환경 지원

2) 필요한 모든 정보를 자체적으로 가지고 있음

3) 웹 서버의 경우 HTTP 헤더에 넣어서 전달 혹은 URL 파라미터로 전달 가능

4) 회원인증, 정보 교환에 사용됨

 

- 구조

aaaaaa.bbbbbb.cccccc

aaaaaa = 헤더(header)

bbbbbb = 내용(payload)

cccccc = 서명(signature)

 

- 헤더

{
	"typ": "JWT", (토큰의 타입을 지정)
    "alg": "HS256" (해싱 알고리즘 지정)
}

- 내용(payload)

{
	"iss": "example.com",
    "exp": "14514514514500",
    "https://example.com/jwt_claims/is_admin": true,
    "userID": "123123123123",
    "username": "Kwon"
}
# 등록 클레임: iss, sub, aud, exp, nbf, sat, jti
# 공개 클레임: URI 형식(충돌 방지)
# 비공개 클레임: 클라이언트와 서버 간의 협의 하에 사용되는 클레임

- 서명(signature): 헤더의 인코딩 값과 정보의 인코딩 값을 합친 후 주어진 비밀키로 해쉬하여 생성