드디어 대망의 10주 서버 스터디가 마무리 되었습니다.
10주차 스터디 복습을 조금 늦게하는 감이 있으나, 마무리를 지어보려고 합니다.
그러면 시작하겠습니다!
10주차 스터디는 로그인 방식(Jwt, Cookie and Session) OAuth, 페이징, 트랜잭션에 대해 학습했다.
먼저 트랜잭션은 최근에 많이 공부했기 때문에 이에 대한 내용은 생략하려고 한다.
트랜잭션에 대한 글은 아래 포스팅에서 확인할 수 있다.
https://devdebin.tistory.com/205?category=1028513
트랜잭션
본 게시글은 인프런 김영한 선생님 강의 스프링 DB 1편을 완강하고 배운 것을 남기고자 적은 포스팅입니다. 강의 링크는 아래와 같습니다. https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-1/das..
devdebin.tistory.com
https://devdebin.tistory.com/32?category=971742
회복과 병행 제어
데이터베이스 관리 시스템은 데이터베이스가 항상 정확하고 일관된 상태를 유지할 수 있도록 다양한 기능을 제공하는데, 그 중심에는 트랜잭션이 있다. 트랜잭션을 관리함으로써 데이터베이스
devdebin.tistory.com
페이징
- 페이징이란 한 화면에서 보여주는 데이터의 범위를 결정하는 일련의 방법.
- 우리가 흔히 접하는 일반적인 웹 게시판이나 조회 화면을 생각하면 된다.
- 조회 대상 데이터가 10만 건이라면 한 화면에서 모두 보여 줄 수는 없다.
한 화면에서 보여 줄 수 있는 범위를 결정하는 것이 페이징이다. - 페이징은 크게 커서 기반 페이징과 오프셋 기반 페이징이 있다.
오프셋 기반 페이징 (Offset-Based)
- 전통적인 페이징 처리다. 제일 많이 활용되며 흔히 커뮤니티, 게시판에서 사용한다.
- 클라이언트는 가져올 데이터의 갯수와 몇 번째 데이터부터 가져올 것인지 DB에게 알려줘야 한다.
- 구현하기 간단하지만, 데이터가 많아지면 성능 저하가 발생한다.
- 오프셋만큼 데이터를 건너야하기 때문에 성능 정하가 발생하는 것이다.
- 예시는 아래와 같다.
SELECT * FROM users
WHERE team_id = %team_id
ORDER BY id DESC
LIMIT 20 OFFSET 40;커서 기반 페이징 (Cursor-Based)
- 오프셋 기반 페이징의 단점을 극복했다. 흔히 무한 스크롤에서 사용한다.
- 클라이언트는 값을 가져오는 기준이되는 포인터를 DB에게 알려줘야 한다.
- 보통 기준 포인터의 기준으로 뒤에 있는 데이터들을 가져온다.
- 구현이 까다롭지만 커서 기반 페이징을 우선으로 구현해야한다고 한다.
- 예시는 아래와 같다.
SELECT * FROM users
WHERE team_id = %team_id
AND id <= %cursor
ORDER BY id DESC
LIMIT %limit
로그인 방식
쿠키와 세션
- Http는 stateless하가 때문에 로그인 같이 회원 정보, 인증을 유지할일이 생기면 보통 쿠키와 세션을 사용한다.
Cookie
- 쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일이다.
- 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있다.
- 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
- 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠키값은 4KB까지 저장한다.
- Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
- 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송한다.
Session
- 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다.
- 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
- 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능 하다.
- 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.
- 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다.
- 클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는 데 이것이 세션 ID다.
쿠키와 세션을 이용한 로그인 방식
- 로그인을 진행한다. 클라이언트가 서버에 접속하면 세션 ID를 발급 받는다.
- 서버는 해당 세션을 만들어 관리하고, 쿠키를 만들어 세션ID를 담아 클라이언트에게 보낸다.
- 이제 클라이언트는서버에 요청할 때, 브라우저는 자동으로 요청 헤더에 쿠키를 담아 서버에 전달한다.
- 그럼 서버가 세션에서 세션 ID를 찾아, 사용자에게 허가되는 요청은 허가하고, 허가되지 않는 요청은 진행하지 않는다.
- 이런 방식으로 요청이 진행된다.
JWT
JWT는 JsonWebToken의 줄임말이다.
쿠키 세션과 더불어 JWT도 로그인을 진행하는 로직에서 많이 사용한다.
JWT 방식은 HTTP Authorization 헤더에 Bearer + token이런 형식으로 값을 넣는다.
JWT는 세 파트로 나누어지며, 각 파트는 점로 구분하여 aaaaaa.bbbbbb.cccccc처럼 구성된다.
순서대로 헤더 (Header), 페이로드 (Payload), 서명 (Sinature)로 구성된다.
header
- 헤더는 2가지 정보를 가지고 있다.
- typ : 토큰의 타입을 지정한다. 토큰의 타입은 JWT다.
- alg : 해싱 알고리즘을 지정한다. 보통 HMAC SHA256, RSA가 사용된다. 토큰을 검증할 때 사용되는 signature에서 활용한다.
{
"typ": "JWT",
"alg": "HS256"
}payload
- 토큰에 담을 정보(데이터, 권한)가 payload에 담겨 있다.
- 여기에 담는 정보의 한 조각을 클레임이라 부르고, 이는 key/value의 한 쌍으로 이루어진다.
- 클레임은 비공개 (private) 클레임, 공개 (public) 클레임, 등록된 (registered) 클레임로 구분된다.
signature
- signature(서명)은 헤더의 인코딩 값과, 정보의 인코딩 값을 합친 후 주어진 비밀키로 해쉬를 하여 생성한다.
- 비밀키로 서명하게 되면 공개키를 통해 검증을 거친다.
또한 이번 실습에서는 커스텀으로 만든 JwtService를 만들어 인증을 진행하는 실습을 진행했다.
OAuth
- OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
흔히 말하는 페이스북 로그인, 구글 로그인, 깃허브 방식등이 있다
OAuth는 개념만 배우고 실습은 하지 않았다. 본인이 알기로는 보통 스프링 시큐리티를 이용해서 OAuth를 진행한다고 한다.
NodeJS에서는 Passport를 사용한 경험이 있다. 구글과 깃허브 라이브러리를 사용해 구현해봤다.
OAuth에 관한 더 자세한 글은 차후에 다룰 예정이다.
많이 늦었지만 이렇게 10주차 스터디를 마무리했습니다!!!!
내일부터 팀 빌딩을 시작하면서 본격적인 프로젝트를 시작합니다.
원하는 팀에 꼭 들어갔으면 좋겠고, 좋은 팀원들 만나서 재밌게 진행했으면 좋겠습니다ㅎㅎ
이상으로 포스팅을 마칩니다. 감사합니다!
참고자료
https://slack.engineering/evolving-api-pagination-at-slack
https://interconnection.tistory.com/74
댓글