1. session방식
입장권에 발급번호만 적혀 있다.
user가 입장권을 제시하면 서버는 메모리/db에 저장해둔 입장권 발급목록에서 해당 입장권의 발급번호를 조회한 후 있으면 들여보내준다.
▶ 동접자가 많을수록 서버부담↑
2. jwt방식 : Json Web Token
- header : 해당 jwt토큰에 대한 정보(토큰유형, 해시 알고리즘...)
- payload : 실제 토큰 정보(유저정보, 권한정보 등 = claim)
- sinature : (header + payload의 정보들을 base64로 인코딩) + secret key를 Header의 해당 alg타입으로 해싱한 값
secret key가 노출되지 않으면 payload를 조작하여 보내도 signature가 다르기 때문에 signature는 토큰의 위변조 여부를 확인하는데 사용된다.
※ JWT에서 자주 사용되는 JSON 키 이름
alg 키: 서명 알고리즘(algorithm)
typ 키: 토큰의 유형(type)
sub 키: 인증 주체(subject)
iss 키: 토큰 발급처(issuer)
iat 키: 발급 시각(issued at)
exp 키: 만료 시한(expiration time)
aud 키: 클라이언트(audience)입장권(access token)에 회원정보, 발급일, 유효기간 등이 명시되어 있다(JSON 형식).
user가 입장권을 제시하면 서버는 입장권에 있는 발급일/유효기간 등만 확인 후 문제없으면 들여보내준다.
▶ 입장권(토큰)만 확인하면 됨(암호화 알고리즘에 의해 만들어진 string만으로 권한정보를 파악할 수 있다)
▶ stateless하다(서버부담↓)
※ RESTful의 stateless(무상태)
: Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
각 API 서버는 Client의 요청만을 단순 처리하며 이전 요청이 다음 요청의 처리에 연관되어서는 안된다.
Server의 처리 방식에 일관성을 부여하여 서버 부하가 줄어들며 서비스 자유도가 향상▶ 디코딩이 매우 쉽기 때문에 입장권(토큰)에는 최소한의 정보만 넣어야 한다
▶ 시크릿키를 털리면 끝장이기때문에
1. 공유X
2. 키는 최대한 길고 어렵게 설정
3. 생성용 키와 검증용 키(private key + public key) 2개 사용
4. 유효기간을 짧게 설정
5. 토큰블랙리스트만들기(but 요청이 들어올때마다 서버에서 블랙리스트와 대조하여 확인해야하므로 session방식의 단점을 답습한다. 추천X)
HttpOnly cookie
jwt(입장권)의 유효기간을 짧게 설정하고 refresh token(새 입장권) 발급
refresh token rotation
해싱(hashing)
가장 많이 쓰이는 암호화 방식 중 하나로
복호화가 가능한 다른 암호화 방식들과 달리, 해싱은 암호화만 가능하다.
여기서 복호화 또는 디코딩(decoding)이란 부호화(encoding)된 데이터를 부호(code)화 되기 전 형태로 바꾸어, 사람이 읽을 수 있는 형태로 되돌려놓는 것이다.
해싱을 사용하는 목적은 데이터 그 자체를 사용하는 것이 아니라 동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이다.
민감한 데이터를 다루어야 하는 상황에서 데이터 유출의 위험성은 줄이면서 데이터의 유효성을 검증하기 위해 사용되는 단방향 암호화 방식이다.
출처 : https://velog.io/@rsuubinn/Backend-%ED%95%B4%EC%8B%B1hashing%EA%B3%BC-%ED%86%A0%ED%81%B0token
