JWT(Json Web Token)
Feb 14, 2024
대칭키 시스템
잠그고 여는 게 동일
한쪽에서 발행과 검증을 한다는 것
그래서 열쇠가 하나이다.
열쇠를 잠근 게 발행, 여는 게 검증
세션은 상태를 저장하지만 토큰은 열쇠만 저장하고 있으면 된다. 즉, 클라이언트의 상태 저장이 필요없으니 stateless이다.
클라이언트가 로그인요청을 할 시, 열쇠로 열리면 인증된 것, 안 열리면 위조, 토큰을 안 들고오면 처음 온 것이다.
클라이언트의 상태 정보를 토큰에다가 기록해두기 때문
이러한 토큰을 열쇠로 열었는데 열린다? 신뢰할 수 있는 정보라고 볼 수 있다.
이 토큰으로 이상한 짓을 할 수 있다.
대칭키는 열쇠가 하나다.
공개키 시스템
CIA란?
보안의 3요소
기밀성(Confidentiality)
무결성(Integrity)
가용성(Availability)
만약 A가 B에게 정보를 보내려 하는데 중간에 C가 끼어들어 훔쳐서 버림 → 기밀성이 깨짐
만약 A가 B에게 정보를 보내려 하는데 C가 훔쳐서 버리고 위조된 문서를 전달. → 무결성이 깨짐
그럼 B는 A가 보내준 정보라 생각하고 받았겠지? → 가용성이 깨짐
이 문제를 해결하기 위해 RSA를 알아야 한다.
공개키의 암호시스템에는 RSA라는 것이 있다.
RSA란?
Public Key(공개키), Private Key(비밀키)
공개키를 암호화했다면, 비밀키로만 열 수 있다.
비밀키를 암호화했다면, 공개키로만 열 수 있다.
이전 문제를 RSA를 적용하여 해결할 수 있다.
A가 비밀번호를 보낼 때, B의 공개키로 암호화를 한 뒤 보낸다.
그럼 C가 중간에 가로채도 C는 내용을 볼 수 없다.
왜? B의 공개키는 반드시 B의 비밀키로만 열 수 있기 때문이다. → 기밀성 문제 해결
누가 보냈는지는 어떻게 인증할까?
A가 보냈다는 의미로 A의 비밀키로 잠그면, 무조건 A의 공개키로만 열려야 한다.
그럼 C가 중간에 낚아채도 열 수가 없다
왜? B의 공개키는 B의 개인키로만 열 수 있기 때문이다.
정리해보면
B는 이제 문서를 받았을 때, 아래와 같이 처리한다.
인증 - A의 공개키로 문서를 열어본다.
열린다? A가 보낸 것이 확실 (인증 완료)
안열린다? A가 보낸 것이 아니므로 열지 않는다.
암호화 - B의 개인키로 열어본다.
열린다? 암호화가 잘 되었다 (암호화 완료)
안열린다? 암호화가 되지 않았다.
공개키 → 비밀키 (암호화에 자주 사용)
비밀키 → 공개키 (전자 서명에 자주 사용)
OAuth
두 가지 방식이 있다.
크리덴셜, 코드
크리덴셜: 토큰을 받는다
코드: 코드를 받는다
둘 다 공개키가 아니면 검증받아야 한다.
Share article
