[Gibeom] Week9 미션

.gitignore

@@ -0,0 +1 @@
+.idea/

Gibeom/umc10th/build.gradle

@@ -22,6 +22,13 @@ dependencies {
     implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
     implementation 'org.springframework.boot:spring-boot-starter-webmvc'
     implementation 'org.springframework.boot:spring-boot-starter-security'
+
+    // Jwt
+    implementation 'io.jsonwebtoken:jjwt-api:0.12.3'
+    implementation 'io.jsonwebtoken:jjwt-impl:0.12.3'
+    implementation 'io.jsonwebtoken:jjwt-jackson:0.12.3'
+    implementation 'org.springframework.boot:spring-boot-configuration-processor'
+
     compileOnly 'org.projectlombok:lombok'
     runtimeOnly 'com.mysql:mysql-connector-j'
     annotationProcessor 'org.projectlombok:lombok'
@@ -31,9 +38,16 @@ dependencies {
     testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
     testAnnotationProcessor 'org.projectlombok:lombok'
 
+    // Security
+    implementation 'org.springframework.boot:spring-boot-starter-security'
+    testImplementation 'org.springframework.security:spring-security-test'
+
     // Swagger
     implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:3.0.1'
     implementation 'org.springdoc:springdoc-openapi-starter-webmvc-api:3.0.1'
+
+    // OAuth
+    implementation 'org.springframework.boot:spring-boot-starter-oauth2-client'
 }
 
 tasks.named('test') {

Gibeom/umc10th/keyword_summary/ch08.md

@@ -0,0 +1,42 @@
+- Spring Security가 무엇인가?
+
+  스프링 기반 애플리케이션의 보안을 담당하는 강력하고 포괄적인 하위 프레임워크
+
+  복잡한 보안 로직을 직접 구현할 필요 없이 표준화된 필터 기반의 설정을 통해 시스템을 안전하게 보호한다.
+
+- 인증(Authentication)vs 인가(Authorization)
+
+  비슷해보이지만 서로 다른 개념이다.
+
+  인증 (Authentication)
+
+    - 본인확인 절차
+    - 사용자가 자신이 주장하는 사람이 맞는지 확인하는 과정
+
+  인가 (Authorization)
+
+    - 권한확인 절차
+    - 인증된 사용자가 특정 리소스에 접근할 수 있는 권한이 있는지 확인하는 과정
+
+- Stateful vs Stateless
+
+  논점 : 서버가 클라이언트의 세션 정보를 기억하는가?
+
+  Stateful(상태유지) : 세션 정보를 기억함
+
+  Stateless(토큰 기반) : 서버가 상태를 유지하지 않으므로 요청에 포함된 토큰(JWT)로 검증
+
+  | 구분 | Stateful | Stateless |
+      | --- | --- | --- |
+  | 특징 | 서버가 세션 저장소에 로그인 상태 유지 | 서버가 상태를 유지하지 않음, 요청에 포함된 토큰으로 검증 |
+  | 인증방식 | JSESSION쿠키를 통해 서버 메모리/DB의 세션 조회 | 매 요청시 HTTP헤더에 토큰을 담아서 전송 (Authorization:Bearer<token>) |
+  | 서버 확장 | 세션 불일치 문제 발생 가능 | 각 요청이 독립적이므로 서버 증설에 유리 |
+  | 메모리 및 비용 | 동시접속자가 많을수록 서버 세션 메모리 소비 증가 | 토큰 검증 연산이 필요하며, 서버 메모리 사용량은 적음 |
+  | 주요 활용처 | 전톤적인 웹 애플리케이션 | REST API, 모바일 앱, MSA |
+
+  서버 확장 방법
+
+    - Scale-up : 단일 서버 성능 향상
+    - Scale-out : 서버의 개수를 늘리기
+    - 로드밸런서 : 서버 부하를 분산시키는 H/W, S/W
+        - 클라이언트와 서버Pool 사이에 위치해 서버의 부하를 분산시키는 하드웨어나 S/W

Gibeom/umc10th/keyword_summary/ch09.md

@@ -0,0 +1,53 @@
+- 세션과 토큰의 차이는?
+
+  세션 방식은 사용자의 정보를 서버가 저장함
+
+    - 이용자 수가 많으면 서버 부하가 커짐(모든 사용자 정보를 테이블로 보유하고 있음)
+
+  토큰 방식은 사용자가 내 정보가 포함된 토큰을 내밀기만 하면 됨
+
+    - 서버의 부담이 적음.
+    - 다만 사용자의 정보를 저장하지 않기 때문에 할 수 없는 기능도 있음.
+
+  세션 : 입장권인데 적혀있는 게 거의 없음. 사이트가 입장권 검사하고 저장해놓음.
+
+  토큰 : 뭐가 많이 적혀있는 입장권. 사이트는 입장권 들고있으면 입장 허용해줌.
+
+  (참고자료) https://youtu.be/XXseiON9CV0?si=Am8JlSoLV0SiZX0W
+
+- 엑세스 토큰과 리프레시 토큰이란?
+
+  액세스 토큰 : 접근하기 위해 필요한 기본적인 토큰, 해킹 공격 방지를 위해 유효기간이 짧다.
+
+  리프레쉬 토큰 : 만료된 액세스 토큰을 재생성해주는 토큰.
+
+- OAuth 1.0과 OAuth 2.0의 차이는?
+
+  OAuth 2.0 은 1.0과 달리 복잡한 암호화 서명 과정을 간소화하고, 웹/모바일 등 다양한 환경에 맞춘 인증 방식을 도입해 속도와 확장성을 대폭 개선한 버전
+
+  핵심 차이점
+
+  | 구분 | OAuth 1.0 | OAuth 2.0 |
+      | --- | --- | --- |
+  | 핵심 매커니즘 | 모든 요청에 디지털 서명 필요 | 발급받은 액세스 토큰만으로 인증 |
+  | 암호화 요구사항 | HTTPS가 필수가 아님 | HTTPS(TLS) 필수 |
+  | 역할의 분리 | 단순함(Client, Server, User) | 인증서버와 리소스 서버의 분리 |
+  | 토큰 만료 | 토큰 만료 개념이 없거나 복잡 | 만료기간이 존재하며, 리프레시 토큰으로 갱신가능 |
+  | 지원 환경 | 웹 브라우저 기반 애플리케이션 중심 | 모바일 앱, Iot, 데스크톱 등 다양한 환경 지원 |
+
+
+  왜 2.0으로 바뀌었을까?
+
+    1. 개발의 복잡성 해결(디지털 서명의 폐지)
+
+       1.0은 API를 호출할 때마다 복잡한 암호화 알고리즘으로 디지털 서명을 생성하고 이를 헤더에 담아 보내야 했음. 이 서명을 만드는 과정이 조금만 틀려도 인증이 실패했기 때문에 매우 불편했음.
+
+       2.0은 이 서명 과정을 과감히 버렸음. 대신 HTTPS통신을 필수로 규정해 연결 자체를 암호화하고, 발급받은 문자열 토큰만 헤더에 얹어서 보내면 되도록 단순화 했음
+
+    2. 모바일 및 다양한 디바이스 지원
+
+       OAuth 1.0이 나올 당시에는 웹브라우저 중심의 환경이었음. 하지만 모바일 앱, IoT 등의 기기들이 생기면서 브라우저가 없거나 화면이 없는 환경에서도 인증을 처리해야 할 필요가 생김. OAuth 2.0은 시나리오별 인증방식을 여러개 제공해 맞춤형 인증을 제공함
+
+    3. 대규모 서비스 분할(확장성)
+
+       OAuth 2.0은 인증을 담당하는 서버와 실제 데이터를 가지고 있는 서버의 역할을 명확히 나눴음. 덕분에 대기업이나 대규모 서비스에서는 인증서버만 따로 구축해 트래픽을 분산할 수 있음.