📄 핵심기능
1. 서버사이드 렌더링(SSR)
SSR은 동적웹페이지 종류의 하나로서 CSR과 달리 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식이다.
정리!
SSR: 서버에서 페이지내용 완성->브라우저에 토스.
CSR: 페이지 내용을 클라이언트에서 완성-> 브라우저가 그려줌.
💻SSR의 장단점
😄장점
-
검색엔진 최적화(SEO)
검색 사이트에서 검색했을 때 사용자에게 결과가 많이 노출될 수 있도록 최적화 하는 기법.
CSR 방식에서 초기HTML에는 컨텐츠가 업슨 빈 껍데기인 상태이다. 검색엔진이 보통 컨텐츠를 검색할 때 js파일의 내용을 읽어들이지 못하기 때문에 문제가 발생한다.
반면에 SSR 방식은 서버에서 컨텐츠를 포함하여 클라이언트측으로 넘겨주기 때문에 검색엔진에서는 컨텐츠를 포함한 내용을 검색할 수 있게 된다. -
빠른 페이지 렌더링
위에서 설명했듯이 서버에서 미리 페이지를 그려 클라이언트에 보내기 때문에 사용자 경험이 개선되고, 사용자 입장에서는 화면이 빠귀는 과정을 보지 않고 최초에 완성된 화면을 볼 수 있게 된다.
🤔단점
- 복잡도와 서버 부하 증가
서버쪽 환경설정(node.js 실행방법등)및 클라이언트,서버 빌드에 대한 이해가 필요하다. 또한 node.js 환경에서는 브라우저 관련 API를 다룰 때 주의사항 또한 존재한다.
그리고 클라이언트측에서의 부하가 없어진 것이 아닌 서버로 넘어간 것이기 때문에 웹서버와 API서버를 분리하는 등 작업이 필요할 수도 있다.
2. JWT(JSON WEB TOKEN)
JWT (JSON Web Token) 는 인증에 필요한 정보들을 암호화시킨 토큰을 의미한다. Access Token (JWT Token) 을 HTTP 헤더에 실어 서버에 전송하고 큰은 임의로 생성된 비밀번호 같이 동작한다.
제한된 수명을 가지고, 새로운 토큰은 한번 만료되면 새로 생성되어야한다.(Refresh Token)
추가정보!
Authentication(인증): == 로그인, 아이디와 패스워드 등을 통해 특정 서비스에 일정권한이 주어진 사용자임을 인증을 받는 것.
Authorization (인가): 사용자가 한번 인증을 받은 후에 그 사용자가 특정 리소스에 액세스할 수 있는지 여부를 결정하는 프로세스.
JWT는 '인가'에 연관된 기술!
💻JWT 구조
- Header, Payload, Signature의 3부분으로 이루어져 있다.
- Json 형태인 각 부분은 Base64로 인코딩 되어 표현된다. 각 부분을 이어주기 위해 .구분자를 반환한다.
- Base64는 암호화된 문자열이 아니고, 같은 문자열에 대해 항상 같은 문자열을 반환한다.
🔎 Header,Payload,Signature
_Hedaer
토큰의 헤더는 typ과 alg 두 가지 정보로 구성된다. alg는 헤더(Header)를 암호화 하는 것이 아니고, Signature를 해싱하기 위한 알고리즘을 지정하는 것이다.
typ: 토큰의 타입을 지정 ex) JWT
alg: 알고리즘 방식을 지정하며, 서명(Signature) 및 토큰 검증에 사용 ex) HS256(SHA256) 또는 RSA
_Payload
JWT의 내용. 페이로드에 있는 속성들을 클레임 셋(Claim Set)이라고 부른다. 클레임 셋은 jwt에 대한 내용(토큰 생성자의 정보, 생성일시,,,)이나 클라이언트와 서버 간 주고받기로 한 데이터들로 구성된다.
(즉, 서버에서 보낼 데이터 - 일반적으로 user의 id, 유효기간 포함)
_Signature
서명(Signature)은 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드이다. 서명(Signature)은 위에서 만든 헤더(Header)와 페이로드(Payload)의 값을 각각 BASE64로 인코딩하고, 인코딩한 값을 비밀 키를 이용해 헤더(Header)에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64로 인코딩하여 생성한다.
💻JWT 인증 절차
-
사용자가 로그인.
-
서버에서 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID 값을 부여한 후 기타 정보와 함께 Payload 에 집어넣음.
-
JWT 토큰의 유효기간을 설정.
-
암호화할 Secret key 를 이용해 Access Token 을 발급.
-
사용자는 Access Token 을 받아 저장 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보냄.
-
서버에서는 해당 토큰의 Verify Signature 를 Secret key 로 복호화한 후, 조작 여부, 유효기간을 확인.
-
검증이 완료되었을 경우, Payload 를 디코딩 하여 사용자의 ID 에 맞는 데이터를 가져옴.
💻JWT 장단점
😄장점
- 별도의 인증저장소X
JWT 의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다. 서버의 확장이나 유지,보수에 유리!
- 확장성의 뛰어남
토큰기반으로 하는 다른 인증시스템에 접근이 가능.
ex)facebook,google,microsoft 등 모두 토큰 기반으로 인증. - 검색엔진 최적화(SEO)
🤔단점
- 유효기간의 문제
이미 발급된 JWT에 대해서는 유효기간이 완료될 때 까지 계속 사용이 가능하다. 해결책은 Access Token 유효기간을 짧게하고 Refresh Token 이라는 새로운 토큰을 발급하여 Access Token이 탈취당해도 상대적으로 피해를 줄일 수 있다.
- Payload 정보의 제한성
Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인 할 수 있다.따라서 유저의 중요한 정보들은 Payload에 넣을 없다.
- JWT의 길이
JWT 의 길이는 길기 때문에 인증이 필요한 요청이 많아질수록 서버의 자원낭비가 발생.
📂 미니프로젝트에서는...
SSR방식과 Flask 프레임워크에서 사용하는 Jinja2 템플릿 엔진 및 JWT 토큰을 사용한 페이지를 만들었다.
프로젝트를 작업하면서 확실히 서버쪽에서 완성하여 템플릿을 보내주니까 속도감이 빠른게 느껴졌고, Jinja2언어를 활용해 더 깔끔하게 데이터를 받았다. 아쉬운 점은 협업 프로젝트라서 분업을 통해서 진행되다보니 JWT 를 다루는 것을 해보지 못하고 팀원의 코드 리딩을 통해 이해했다. 개인적으로 나중에 쿠키/세션 방식도 같이 공부해서 비교해 가며 작업을 해보고 싶다. 그 외에는 팀원들과의 호흡이 잘 맞아 팀장으로서 고마웠다. 서로 의견들을 나누면서 하고 싶은 기능들도 90%이상 채웠고, 실력 또한 좋아 팀원들에게 많이 배워간 시간이었다. 나머지 항해 기간에도 부족한 점을 채워가며 성장하고 싶다.
미니프로젝트 깃허브 주소
참고자료
jinja2 템플릿 언어
기본문법 참고: https://gunbin91.github.io/python/2018/09/14/python_f_jinja.html
렌더링 방식 참고:
https://velog.io/@passion10377/jinja2%EB%A1%9C-%EB%A0%8C%EB%8D%94%EB%A7%81-%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95
