클라이밍하는 개발자

JWT란 무엇인가?

JWT는 JSON Web Token의 약자로, JSON 형태의 데이터를 네트워크를 통해 안전하게 전송하기 위해 설계된 방식입니다. JWT는 마치 편지와 같은 구조를 가지고 있습니다:

• 봉투 (Header): 토큰의 타입과 사용된 알고리즘 정보
• 편지지 (Payload): 실제 전달하려는 데이터 (Claims)
• 서명 (Signature): 토큰의 유효성을 검증하기 위한 서명

JWT의 구조

JWT는 세 부분으로 구성되며, 각 부분은 Base64로 인코딩되어 점(.)으로 구분됩니다:

header.payload.signature

JWT의 핵심: 서명(Signature)

서명은 JWT의 무결성을 보장하는 핵심 요소입니다. 서명 과정은 다음과 같습니다:

• 비밀키(Secret Key)를 사용
• 헤더와 페이로드를 입력으로 사용
• 지정된 알고리즘(예: HMAC)으로 서명 생성

JWT의 활용 분야

JWT는 다양한 분야에서 활용되지만, 가장 흔한 용도는 인증(Authentication)입니다. 주요 활용 분야는 다음과 같습니다:

• 인증
• 정보 공유
• 권한 부여
• 단일 로그인(SSO)
• 서버 간 통신

JWT 기반 인증 과정

로그인

• 사용자가 로그인 정보 제공
• 서버가 정보 확인 후 JWT 생성 및 클라이언트에 전송

인증

• 클라이언트가 JWT를 서버에 전송
• 서버가 JWT를 검증
• 검증 성공 시 요청 처리

JWT의 장점

• 서버 부하 감소: 세션 저장소가 필요 없음
• 확장성: 다중 서버 환경에서 유리
• 클라이언트 측 저장: 필요한 정보를 페이로드에 포함 가능

JWT의 단점

1. 토큰 크기: JWT는 모든 정보를 자체적으로 포함하므로, 토큰 크기가 상대적으로 클 수 있습니다. 이는 네트워크 대역폭 사용량을 증가시킬 수 있습니다.
2. 보안 위험: 토큰 탈취: JWT가 탈취되면, 만료되기 전까지 공격자가 사용할 수 있습니다.
3. 토큰 무효화의 어려움: 일단 발급된 JWT는 만료 전까지 유효하며, 개별 토큰을 즉시 무효화하기 어렵습니다. 이는 보안 문제 발생 시 대응을 어렵게 만들 수 있습니다.
4. 갱신 로직의 복잡성: 토큰 만료 관리와 갱신 프로세스가 복잡할 수 있습니다.
5. 상태 저장의 한계: JWT는 기본적으로 무상태(stateless)이므로, 사용자 상태 변경을 실시간으로 반영하기 어려울 수 있습니다.
6. 암호화 부재: 기본 JWT는 서명은 되지만 암호화되지 않아, 중요한 정보는 페이로드에 포함시키지 말아야 합니다.
7. 구현의 복잡성: 올바른 JWT 구현과 관리는 복잡할 수 있으며, 잘못 구현 시 보안 취약점이 발생할 수 있습니다.
8. 만료 시간 설정의 딜레마: 짧은 만료 시간은 보안에 유리하지만 사용자 경험을 해칠 수 있고, 긴 만료 시간은 그 반대입니다.

JWT 실습

JWT.io 사이트를 통해 JWT를 직접 생성하고 검증해볼 수 있습니다. 이를 통해 JWT의 구조와 작동 방식을 실제로 확인할 수 있습니다.

결론

JWT는 현대 웹 애플리케이션에서 인증과 정보 교환을 위한 효율적이고 안전한 방법을 제공합니다. 그러나 보안을 위해 적절한 사용과 관리가 필요합니다. JWT의 이해는 웹 개발자에게 필수적인 지식이 되어가고 있습니다.

출처

https://www.youtube.com/watch?v=36lpDzQzVXs

인증과 인가의 기본 개념

• 인증(Authentication): 사용자의 신원을 확인하는 과정 (놀이공원 입장권)
• 인가(Authorization): 인증된 사용자에게 특정 리소스에 대한 접근 권한을 부여하는 과정 (놀이공원에서만 사용가능)

인증 방법의 발전

3.1. 기본 인증

- 사용자 ID와 비밀번호를 직접 입력

- 보안상 취약점 존재

3.2. 쿠키/세션 기반 인증

- 브라우저의 쿠키를 이용한 사용자 정보 저장 (클라이언트 저장)

- 서버 측 세션 관리의 도입 (서버 저장)

3.3. 토큰 기반 인증

- JWT(JSON Web Token) 활용

- 무상태성(Stateless) 구현으로 서버 부하 감소

- 토큰 기반 인증의 구체적 구현

4.1. 액세스 토큰과 리프레시 토큰

- 액세스 토큰: 짧은 유효기간, 실제 인증에 사용

- 리프레시 토큰: 긴 유효기간, 액세스 토큰 갱신에 사용

4.2. 토큰 기반 인증의 장단점

장점: 서버 확장성 개선, DB 조회 최소화

단점: 토큰 탈취 시 보안 위험

보안 강화 방법

- HTTPS 사용

- HttpOnly 옵션 활용

- 토큰 만료 시간 조절

기타 고려사항

- OAuth를 통한 외부 서비스 인증

- 인증 서버 분리

- SSL/TLS 활용

결론

인증과 인가 구현은 보안과 사용자 편의성 사이의 균형을 맞추는 과정입니다. 서비스의 특성과 요구사항에 맞는 최적의 방식을 선택하는 것이 중요합니다.

OAuth 2.0이란?

OAuth 2.0은 서로 다른 서비스 간에 안전하게 인증과 권한 부여를 할 수 있게 해주는 표준 프로토콜입니다. 이를 통해 사용자의 민감한 정보를 직접 공유하지 않고도 다른 서비스의 기능을 이용할 수 있습니다.

OAuth 2.0이 필요한 이유

예를 들어, '우아한 캘린더'라는 서비스를 만들었다고 가정해봅시다. 이 서비스는 구글 캘린더와 연동하여 일정을 관리하려고 합니다. OAuth 2.0 없이는 다음과 같은 문제가 발생할 수 있습니다

• 사용자의 구글 아이디와 비밀번호를 직접 받아야 함
• 보안 위험 증가
• 불필요한 접근 권한 발생

OAuth 2.0을 사용하면 이러한 문제를 해결할 수 있습니다.

OAuth 2.0의 주요 개념

• Resource Owner: 사용자
• Client: 우리가 만든 서비스 (예: 우아한 캘린더)
• Authorization Server: 인증을 담당하는 서버 (예: 구글)
• Resource Server: 실제 데이터를 제공하는 서버 (예: 구글 캘린더)

OAuth 2.0의 동작 과정

1. 사용자가 우아한 캘린더에서 "구글 로그인" 버튼 클릭
2. 구글의 로그인 페이지로 리다이렉트
3. 사용자가 구글에 직접 로그인
4. 구글이 우아한 캘린더에 권한 코드 전달
5. 우아한 캘린더가 권한 코드로 액세스 토큰 요청
6. 구글이 액세스 토큰 발급
7. 우아한 캘린더가 액세스 토큰으로 구글 캘린더 데이터 접근

OAuth 2.0의 장점

• 보안 강화: 사용자의 비밀번호를 직접 다루지 않음
• 권한 제한: 필요한 기능에만 접근 가능
• 사용자 경험 개선: 별도의 회원가입 없이 기존 계정으로 로그인 가능

OAuth 2.0 구현 시 주의사항

• HTTPS 사용 필수
• 클라이언트 ID와 시크릿 안전하게 보관
• Redirect URI 정확히 설정

소셜 로그인과 OAuth 2.0

OAuth 2.0은 주로 소셜 로그인 구현에 사용됩니다. 하지만 OAuth 2.0은 인가(Authorization)를 위한 프로토콜이며, 인증(Authentication)을 위해서는 OpenID Connect라는 추가적인 레이어가 사용됩니다.

결론: OAuth 2.0은 현대 웹 서비스에서 필수적인 보안 프로토콜입니다. 이를 통해 사용자의 정보를 안전하게 보호하면서도 다양한 서비스 간의 연동을 가능하게 합니다. 개발자로서 OAuth 2.0의 개념과 흐름을 이해하는 것은 매우 중요합니다.

출처

https://www.youtube.com/watch?v=Mh3LaHmA21I

[추천링크]

https://hongong.hanbit.co.kr/%EC%99%84%EB%B2%BD-%EC%A0%95%EB%A6%AC-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%ED%86%A0%ED%81%B0-%EC%BA%90%EC%8B%9C-%EA%B7%B8%EB%A6%AC%EA%B3%A0-cdn/

쿠키 (Cookie)

쿠키는 웹사이트가 사용자의 브라우저에 저장하는 작은 데이터 조각입니다.

예시: 쿠키는 마치 온라인 쇼핑몰에서 받은 쿠폰북과 같습니다. 이 쿠폰북에는 여러분이 방문한 매장, 관심 있는 상품, 장바구니에 담은 물건 등을 메모할 수 있습니다. 여러분이 직접 들고 다니면서 수정할 수 있죠.

주요 특징

• 사용자의 브라우저에 저장됩니다.
• 사용자가 직접 수정할 수 있습니다.
• 보안에 민감한 정보는 저장하지 않는 것이 좋습니다.

세션 (Session)

세션은 서버에서 사용자의 상태 정보를 저장하고 관리하는 방법입니다.

예시: 세션은 백화점의 고객 관리 시스템과 비슷합니다. 고객이 VIP 라운지에 들어가면, 백화점은 고객의 ID를 확인하고 내부 시스템에서 고객 정보를 관리합니다. 고객은 자신의 정보를 직접 수정할 수 없고, 백화점만이 관리할 수 있습니다.

주요 특징

• 서버에서 관리됩니다.
• 사용자가 직접 수정할 수 없어 보안성이 높습니다.
• 서버에 부하가 갈 수 있습니다.

토큰 (Token)

토큰은 사용자 인증을 위해 발급되는 암호화된 문자열입니다.

예시: 토큰은 놀이공원의 입장 팔찌와 유사합니다. 입구에서 티켓을 구매하면 특별한 팔찌를 받게 되는데, 이 팔찌에는 암호화된 정보가 들어있습니다. 놀이공원 내의 각 시설에서는 이 팔찌를 스캔해 입장 자격을 확인합니다.

주요 특징

• 서버에서 발급하고 클라이언트가 보관합니다.
• 암호화되어 있어 위조가 어렵습니다.
• 서버의 부하를 줄일 수 있습니다.

캐시 (Cache)

캐시는 자주 사용되는 데이터를 임시로 저장해두는 장소입니다.

예시: 캐시는 카페의 진열장과 같습니다. 자주 주문되는 케이크는 주방에서 매번 만들지 않고 진열장에 미리 준비해둡니다. 손님이 주문하면 바로 제공할 수 있어 시간과 노력을 절약할 수 있죠.

주요 특징

• 자주 사용되는 데이터를 빠르게 접근할 수 있는 곳에 저장합니다.
• 서버의 부하를 줄이고 응답 속도를 높입니다.
• 데이터의 일관성 관리에 주의가 필요합니다.

결론

이 네 가지 개념은 각각 고유한 특징과 용도를 가지고 있습니다:

• 쿠키: 사용자 브라우저에 간단한 정보 저장 (클라이언트 저장)
• 세션: 서버에서 중요한 사용자 정보 관리 (서버 저장)
• 토큰: 안전한 사용자 인증 수단
• 캐시: 빠른 데이터 접근을 위한 임시 저장소

웹 개발에서 이 개념들을 적절히 활용하면 보안성, 효율성, 사용자 경험을 모두 향상시킬 수 있습니다. 각 상황에 맞는 적절한 기술을 선택하는 것이 중요합니다.

1.JWT (JSON Web Token)란?

JWT는 당사자 간에 정보를 JSON 객체로 안전하게 전송하기 위한 컴팩트하고 독립적인 방식을 정의하는 개방형 표준입니다.

주요 특징:

• 구조: Header, Payload, Signature 세 부분으로 구성
• 사용 사례: 인증 및 정보 교환
• 장점: 상태를 저장할 필요가 없어 서버 부하 감소

JWT 작동 방식:

1. 사용자 로그인
2. 서버가 JWT 생성 및 클라이언트에 전송
3. 클라이언트가 후속 요청에 JWT 포함
4. 서버가 JWT 검증 후 요청 처리

2. OAuth란?

OAuth는 사용자 데이터에 대한 접근 권한을 제3자 애플리케이션에 부여할 수 있게 하는 개방형 표준 프로토콜입니다.

주요 특징

• 버전: OAuth 1.0과 OAuth 2.0 (더 널리 사용됨)
• 목적: 안전한 위임 접근
• 역할: Resource Owner, Client, Authorization Server, Resource Server

OAuth 2.0 승인 흐름

1. 클라이언트가 리소스 소유자에게 권한 요청
2. 리소스 소유자가 승인 부여
3. 클라이언트가 인증 서버에 액세스 토큰 요청
4. 인증 서버가 액세스 토큰 발급
5. 클라이언트가 액세스 토큰으로 보호된 리소스 접근

3. JWT vs OAuth

• JWT는 토큰 형식이고, OAuth는 권한 부여 프로토콜입니다.
• JWT는 주로 인증에 사용되고, OAuth는 권한 부여에 중점을 둡니다.
• OAuth는 JWT를 토큰 형식으로 사용할 수 있습니다.

보안 고려사항

• JWT: 서명 검증, 만료 시간 설정, 민감한 정보 암호화
• OAuth: HTTPS 사용, 상태 매개변수 검증, 안전한 클라이언트 비밀 관리

구현 팁

• JWT: jsonwebtoken 라이브러리 (Node.js)
• OAuth: Passport.js (Node.js), Spring Security OAuth (Java)

결론

JWT와 OAuth는 현대 웹 애플리케이션의 보안과 사용자 경험을 향상시키는 강력한 도구입니다. 개발자는 이들의 작동 원리와 적절한 사용 사례를 이해하고 있어야 합니다.

1. RESTful API 개요

RESTful API(Representational State Transfer API)는 웹 서비스 설계를 위한 아키텍처 스타일입니다. REST 원칙을 따르는 API는 확장성, 유연성, 독립성을 갖추며 웹 서비스 간 효율적인 통신을 가능하게 합니다.

1.1 REST의 주요 원칙

• 클라이언트-서버 구조
• 무상태(Stateless)
• 캐시 가능(Cacheable)
• 계층화 시스템(Layered System)
• 균일한 인터페이스(Uniform Interface)

2. RESTful API 설계 기본

2.1 리소스 식별

URI를 통해 리소스를 명확하게 식별합니다.

예시:

• 좋은 예: /users/123
• 나쁜 예: /api/get-user?id=123

2.2 HTTP 메소드 활용

리소스에 대한 동작을 HTTP 메소드로 표현합니다.

• GET: 리소스 조회
• POST: 새 리소스 생성
• PUT: 리소스 전체 수정
• PATCH: 리소스 일부 수정
• DELETE: 리소스 삭제

2.3 상태 코드 활용

적절한 HTTP 상태 코드를 사용하여 요청 결과를 표현합니다.

• 200: 성공
• 201: 생성 성공
• 400: 잘못된 요청
• 404: 리소스 없음
• 500: 서버 오류

3. RESTful API 설계 모범 사례

3.1 버전 관리

API 버전을 URI에 포함시켜 관리합니다. 예: /api/v1/users

3.2 페이지네이션

대량의 데이터를 다룰 때 페이지네이션을 구현합니다. 예: /api/v1/users?page=2&limit=20

3.3 필터링, 정렬, 검색

쿼리 파라미터를 활용하여 데이터 조작을 지원합니다. 예: /api/v1/users?sort=name&order=asc&search=john

3.4 HATEOAS (Hypermedia as the Engine of Application State)

API 응답에 관련 리소스의 링크를 포함시킵니다.

4. RESTful API 보안

4.1 인증과 인가

• JWT(JSON Web Tokens)를 활용한 인증
• OAuth 2.0을 이용한 제3자 인증

4.2 HTTPS 사용

모든 API 통신에 HTTPS를 적용하여 데이터 암호화

4.3 요청 제한(Rate Limiting)

API 남용을 방지하기 위해 요청 횟수 제한 구현

5. 결론

RESTful API는 현대 웹 개발에서 핵심적인 역할을 합니다. 올바른 설계 원칙을 따르면 확장 가능하고, 유지보수가 쉬우며, 클라이언트-서버 간 효율적인 통신을 구현할 수 있습니다.

개발자로서 RESTful API의 기본 원칙을 이해하고, 설계 모범 사례를 따르며, 보안에 주의를 기울이는 것이 중요합니다. 이를 통해 더 나은 웹 서비스를 개발하고, 다른 개발자들과 원활하게 협업할 수 있습니다.

RESTful API는 계속 진화하고 있으며, GraphQL과 같은 새로운 기술도 등장하고 있습니다. 따라서 최신 트렌드를 주시하고 지속적으로 학습하는 것이 필요합니다.

1. 데이터베이스 스케줄러 개요

데이터베이스 스케줄러는 특정 시간이나 주기적으로 데이터베이스 작업을 자동으로 실행하는 도구입니다. 이는 데이터 관리, 성능 최적화, 보고서 생성 등 다양한 목적으로 사용됩니다.

1.1 스케줄러의 주요 기능

• 정기적인 데이터 정리 및 아카이빙
• 주기적인 통계 및 보고서 생성
• 데이터베이스 유지보수 작업 자동화
• 데이터 백업 및 복구 프로세스 관리

2. MySQL에서의 스케줄러 구현

MySQL에서는 이벤트 스케줄러를 통해 예약된 작업을 실행할 수 있습니다.

2.1 이벤트 스케줄러 활성화

먼저, MySQL 서버에서 이벤트 스케줄러를 활성화해야 합니다:

SET GLOBAL event_scheduler = ON;

2.2 이벤트 생성 예시

다음은 매일 자정에 30일 이상 된 로그를 삭제하는 이벤트 예시입니다:

DELIMITER //
CREATE EVENT daily_log_cleanup
ON SCHEDULE EVERY 1 DAY
STARTS '2024-07-25 00:00:00'
DO
BEGIN
    DELETE FROM logs WHERE created_at < DATE_SUB(NOW(), INTERVAL 30 DAY);
END //
DELIMITER ;

2.3 이벤트 관리

이벤트 조회 / 삭제 / 수정

//이벤트 조회
SHOW EVENTS;

//이벤트 삭제
DROP EVENT IF EXISTS daily_log_cleanup;

//이벤트 수정
ALTER EVENT daily_log_cleanup
ON SCHEDULE EVERY 2 DAY
ENABLE;

3. 스케줄러 활용 사례

3.1 주기적인 데이터 집계

매주 월요일 새벽 2시에 주간 판매 통계를 생성하는 예시:

DELIMITER //
CREATE EVENT weekly_sales_summary
ON SCHEDULE EVERY 1 WEEK
STARTS '2024-07-29 02:00:00'
DO
BEGIN
    INSERT INTO sales_summary (week, total_sales)
    SELECT 
        YEARWEEK(order_date) as week,
        SUM(total_amount) as total_sales
    FROM orders
    WHERE order_date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
    GROUP BY YEARWEEK(order_date);
END //
DELIMITER ;

3.2 데이터베이스 최적화

DELIMITER //
CREATE EVENT monthly_db_optimization
ON SCHEDULE EVERY 1 MONTH
STARTS '2024-08-01 03:00:00'
DO
BEGIN
    -- 모든 테이블 최적화
    DECLARE done INT DEFAULT FALSE;
    DECLARE tbl_name VARCHAR(255);
    DECLARE cur CURSOR FOR SELECT table_name FROM information_schema.tables WHERE table_schema = DATABASE();
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

    OPEN cur;
    read_loop: LOOP
        FETCH cur INTO tbl_name;
        IF done THEN
            LEAVE read_loop;
        END IF;
        SET @stmt = CONCAT('OPTIMIZE TABLE ', tbl_name);
        PREPARE stmt FROM @stmt;
        EXECUTE stmt;
        DEALLOCATE PREPARE stmt;
    END LOOP;
    CLOSE cur;
END //
DELIMITER ;

매월 1일 새벽 3시에 데이터베이스 최적화를 수행하는 예시:

1. 트리거 (Trigger)

1.1 트리거란?

트리거는 데이터베이스에서 특정 이벤트(삽입, 수정, 삭제 등)가 발생했을 때 자동으로 실행되는 프로그래밍 로직입니다. 이는 데이터의 무결성을 유지하고, 복잡한 비즈니스 로직을 구현하는 데 도움을 줍니다.

1.2 트리거의 주요 용도

• 데이터 유효성 검사
• 자동 값 생성 또는 수정
• 관련 테이블 동기화
• 감사(Audit) 로그 생성

1.3 MySQL에서의 트리거 예시

다음은 새 주문이 추가될 때마다 재고를 자동으로 감소시키는 트리거 예시입니다:

DELIMITER //
CREATE TRIGGER after_order_insert
AFTER INSERT ON orders
FOR EACH ROW
BEGIN
    UPDATE products
    SET stock = stock - NEW.quantity
    WHERE id = NEW.product_id;
END //
DELIMITER ;

이 트리거는 orders 테이블에 새 주문이 삽입된 후 실행되며, products 테이블의 해당 상품 재고를 감소시킵니다.

2. 튜닝 (Tuning)

2.1 튜닝이란?

튜닝은 시스템이나 애플리케이션의 성능을 최적화하는 과정입니다. 데이터베이스 튜닝, 쿼리 튜닝, 서버 튜닝 등 다양한 영역에서 이루어질 수 있습니다.

2.2 튜닝의 주요 영역

• 데이터베이스 튜닝
• 쿼리 최적화
• 서버 구성 튜닝
• 애플리케이션 코드 최적화

2.3 MySQL 쿼리 튜닝 예시

최적화 전 쿼리:

SELECT * FROM users 
WHERE created_at > '2024-01-01' 
AND status = 'active';

최적화 후 쿼리:

SELECT id, name, email FROM users 
WHERE created_at > '2024-01-01' 
AND status = 'active'
LIMIT 1000;

이 예시에서는 다음과 같은 최적화를 수행했습니다:

1. 필요한 컬럼만 선택 (SELECT * 대신)
2. 결과 제한 (LIMIT 사용)
3. 인덱스 사용 가능성 향상 (created_at과 status 컬럼에 복합 인덱스 생성 고려)

3. 트리거와 튜닝의 연관성

트리거와 튜닝은 밀접한 관련이 있습니다. 트리거는 데이터베이스 작업을 자동화하고 일관성을 유지하는 데 도움이 되지만, 과도한 사용은 성능 저하를 초래할 수 있습니다. 따라서 트리거 설계 시 성능을 고려한 튜닝이 필요합니다.

3.1 트리거 튜닝 팁

1. 필요한 경우에만 트리거 사용
2. 트리거 내 로직을 최대한 간단하게 유지
3. 트리거 실행 시점(BEFORE/AFTER) 적절히 선택
4. 트리거 내에서 무거운 쿼리 피하기

4. 결론

트리거와 튜닝은 개발자가 반드시 이해하고 적절히 활용해야 할 중요한 개념입니다. 트리거를 통해 데이터의 일관성과 무결성을 유지하면서도, 적절한 튜닝을 통해 시스템의 전반적인 성능을 최적화할 수 있습니다.

트리거 사용 시에는 그 필요성을 신중히 검토하고, 성능에 미치는 영향을 고려해야 합니다. 튜닝은 지속적인 과정으로, 시스템의 변화와 사용 패턴에 따라 계속해서 수행되어야 합니다.

효과적인 트리거 설계와 지속적인 성능 튜닝을 통해, 개발자는 더 안정적이고 효율적인 시스템을 구축할 수 있습니다. 이는 결과적으로 사용자 경험 향상과 비즈니스 목표 달성에 크게 기여할 것입니다.