1. Toy - 33일차
- 가장 긴 오름차순 부분배열을 구하는 문제
1) 부분배열을 구한다
2) 오름차순인지 확인한다
3) max와 부분배열의 길이를 비교해 더 긴것을 max에 할당
의 순서로 생각을 했다
일단 부분배열을 구하는데에 너무 많은 시간이 소모됨
효율적인 알고리즘은 O(N^2)이라고함
2. 인증/보안 - Token
-
토큰기반 인증
세션기반 인증 => 서버(or DB)에 유저 정보를 담는 방식, 서버에 부담
부담을 클라이언트에 분산시키기 위함 => 토큰기방 인증
토큰은 유저정보를 암호화하고 있어, 클라이언트에 담아도 무리가 없음 -
JWT (Json Web Token)
Json포맷으로 사용자에 대한 속성을 저장하는 웹 토큰
header.payload.signature
Header
토큰의 종류, 암호화 알고리즘 JSON형태 => base64로 인코딩
Payload
유저의 정보, 권한, 기타 정보 JSON형태 => base64로 인코딩
Signature
Header와 Payload를 base64인코딩한 값과 salt값과 조합으로 암호화된 값
ex)
HMAC SHA256(base64(header)+'.'+base64(payload) , secret(salt값))
-
인증 절차
=> 요청 / 토큰 생성
<= 토큰
=> 요청(with 토큰) / 토큰 해독, 해당 요청 응답
<= 응답 -
특징
1) 무상태성 & 확장성
서버는 클라이언트에 대한 정보를 저장할 필요가 없음
토큰을 헤더에 추가함으로 인증절차 완료
2) 안정성
암호화한 토큰 사용
암호화 키를 노출 할 필요 없음
3) 어디서나 생성 가능
토큰을 생성하는 서버가 꼭 토큰을 만들지 않아도 됨
4) 권한 부여에 용이
토큰의 내용(Payload)에 접근 정보를 정의할 수 있음
종류
1) Access Token
2) Refresh Token
Access Token은 보호된 정보들에 접근할 수 있는 권한부여에 사용, 짧은 유효기간이 좋음(탈취되면 위험!)
Refresh Token은 Access Token이 만료되면 Refresh Token을 사용하여 새로운 Access Token을 발급 받음 => Refresh Token도 탈취당하면 문제가 되기에, 정보가 민감한 사이트들은 Refresh Token을 사용하지 않음
3. Token sprint
- 인증서
mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1
mkcert -key-file 파일명.pem -cert-file 파일명.pem localhost IPv4 IPv6
localhost와 IPv4, IPv6에서 사용할 수 있는 인증서임
-
express cookie
res.cookie 쿠키 설정
req.cookies 쿠키 확인 -
axios
res.data 안에 서버에서 보낸 응답 payload가 담겨있다
payload의 data라는 키를 조회하려면
res.data.data로 조회했어야함
review
-
도메인을 신뢰하는 process
- 브라우저는 CA 리스트를 알고있음
- 서버는 CA 기관을 통해 발급받은 SSL 인증서를(Public key로 암호화) 사용자에게 전달
- 브라우저는 SSL 인증서가 CA 리스트에 포함되어 있는지 확인
- 브라우저는 SSL 인증서를 복호화 함
- 복호화에 성공했으면, 신뢰가능하다고 판단
-
httpOnly와 secure가 true일 경우에만 sameSite = none이 가능
-
CSRF 서버가 클라이언트의 쿠키 정보를 너~무 믿어서 생기는 공격
-
samesite >> 최상위 도메인을 비교
