📌인증
- Authentication : 식별 가능한 정보로 서비스에 등록된 유저의 신원을 입증하는 과정
📌인가
- Authorization : 인증된 사용자에 대하여 자원의 접근권한을 확인하는 것
📌쿠키란
- 쿠키는 Key-Value 형식의 문자열 덩어리
- 클라이언트의 브라우저에 설치되는 파일임

📖세션 쿠키
- 만료 시간을 서버측에서 지정하지 않은 쿠키
- 일반적으로 브라우저가 종료되면 세션이 종료되었다고 보고 삭제(브라우저마다 상의)
📖지속 쿠키
- 만료 시간을 서버측에서 지정한 쿠키
- 파일로 저장되므로 브라우저가 종료되어도 쿠키는 존재
- 지정한 시간 만료 또는 날짜이후에 삭제
❗쿠키 특징
- 보안에 취약(쿠키 값을 그대로 보냄, 중요하지 않은 내용에만 사용해야함)
- 용량 제한
- 브라우저간 공유 불가
- 네트워크 부하
📌세션 인증
- 중요한 정보를 쿠키처럼 브라우저에 파일로 저장하지 않고 서버측에 저장
- 세션 ID만 쿠키에 담아 주고받으며 서버에서는 세션 ID로 정보를 조회

❗세션 특징
- 세션 저장소를 사용하여 서버에 부하
- 세션을 유지해야하며 세션의 종료시점은 서버측에서 정한다
📌토큰 인증
- 토큰 자체에 데이터를 담아 통신
- 앱에서는 쿠키와 세션이 없어 토큰을 주로 사용

❗토큰 특징
📌JWT
- Json Web Token
- 로그인 이후 서버가 만들어서 유저에게 넘겨주는 암호화된 문자열
- 세션 ID만 쿠키에 담아서 통신하는 방식과 달리 실제 암호화된 정보들을 주고받으므로 보안에 굉장히 주의 해야함
📖구조

- typ : 토큰의 타입 지정(JWT를 의미)
- alg : 해싱 알고리즘 지정 HMAC-SHA256 혹은 RSA
payload
- 토큰에 담을 정보가 있는 부분(실제 통신할 내용)
- 정보 한 조각을 클레임이라 하며 이 클레임 1개는 Json형태로 한쌍의 key/value로 이루어짐, 토큰에는 여러개의 클레임들을 넣을 수 있다
signature
- header와 payload, 서버고유키를 가지고 특정 알고리즘을 사용, 문자열로 변환
- 중간에 탈취당하여 payload를 변경하면? signature 유효한 값이 달라져서 거부(해커는 서버고유키를 몰라서 변경한 payload에 해당하는 올바른 signature를 모름)
- 유효성 검증시 사용하는 암호화 코드
📖주의점
- JWT는 payload 부분자체가 암호화 되어있는 것은 아니다, 탈취당하면 바로 정보 노출가능
- 즉, 비밀번호와 같은 민감한 정보는 넣으면 안됨
- 정보보호가 목적이 아닌 위조 방지를 목적으로 사용해야 한다
📖동작 과정
- 쿠키를 주고받는 과정과 동일
- 인증시 Token을 발급해주고 이후 Token을 클라이언트에서 요청시마다 같이 보냄

📖Access Token, Refresh Token
- Access Token : 위에서 설명한 일반적인 토큰, 짧은 수명
- Refresh Token : 새로운 Access Token을 발급해주기 위한 토큰, 보통 DB에 유저정보와 해당 Refresh Token을 저장한다, 긴 수명
📖프론트에서 Token 안전하게 관리
- 프론트에서 token을 관리하는 곳은 보통 local storage 또는 cookie
- 하지만 두 곳모두 XSS, CSRF 등 공격에 취약
- httpOnly 옵션 : JS로 접근이 불가능하게 함
- secure 옵션 : https 접속에서만 동작
출처 및 참고 : https://tansfil.tistory.com/59, https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC,