인증(Authentication)이란 ?
유저의 dentification을 확인하는 절차입니다 (유저의 아이디와 비밀번호를 확인하는 절차)
인증을 하기 위해서는 먼저 유저의 아이디와 비밀번호를 생성할 수 있는 기능이 필요할것이다.
인증은 왜 필요할까 ?
- 우리 서비스를 누가 쓰며 어떻게 사용하고 있는지 추적이 가능하도록 하기 위해 필요함.
- 인증에 필요한 것은 무엇이 있을까요 ?
ㄴ ID, Email, Password
ㄴ 가장 중요한 것은 Password
비밀번호는 어떻게 관리해야 하는가 ?
- 데이터베이스에 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함.
- 통신 시 개인 정보를 주고받을 때 SSL을 적용하여 암호화(HTTPS)
암호화는 어떻게 할까 ?
- 단방향 해쉬
ㄴ 본래 해쉬함수는 자료구조에서 빠른 자료의 검색 , 데이터의 위변조 체크를 위해 쓰지만 복원이 불가능한 단방향 해쉬함수는 암호화적 용도로 사용된다.
ㄴ "1234" 를 SHA-256 해싱하면 다음과 같다
03ac674216445fg352se451121546a41d231564d68a1d53153413125
ㄴ 결과만 봐서는 당장 식별이 불가능하므로 완벽해보입니다.
ㄴ 하지만 같은 알고리즘으로 "1234" 다시 해싱하면 항상 같은 결과가 나타난다.
ㄴ 이와 같은 허점을 이용해 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스도 존재한다.
ㄴ 레이보우 테이블 이라고 부르는데 이러한 레인보우 테이블을 이용해서 해시값을 유추해주는 사이트도 존재한다.
ㄴ 이같은 허점을 보완하고자 Salting key stretching 라는 것이 생겨낫다.
- 단순 해쉬값이 해킹에 쉽게 노출되기 때문에 솔팅 이라는 아이디어가 생겨낫다.
- 입력한 비밀번호와 임의로 생성한 문자열을 합쳐서 해싱해서 이 해시값을 저장하는 방법
- 물론 이때 비교를 위해 해시값과 소금 값을 같이 저장해야한다.
- 여기에 해커가 패스워드 무작위 대입을 통해 해시값을 계산하는데 필요한 시간을 대폭늘리기 위해 솔팅 및 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것이 키 스트랫칭입니다.
bcrypt
salting & key 스트렛칭 대표적 라이브러리
- 빅크립트는 앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적인 라이브러리 입니다.
- 다양한 언어를 지원하고 있으며, 사용이 간편하여 쉽게 적용이 가능합니다.
- 빅크립트는 해쉬 결과값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 데이터베이스 설꼐 를 복잡하게 할 필요가 없다ㅏ.
-빅크립트를 통화 해싱된 결과값 의 구조는 아래와 같다.
인가
- 해당 유저가 리퀘스트에 해당하는 권한이 있는지 확인하는 절차
- http의 특징은 ?
ㄴ 바로 request / response 요청과 응답.
ㄴ stateless한 성질(저장하지 않는 성질)
서버는 사용자가 로그인 했을경우 , 로그인 했다는 것을 어떻게 알수 있을까 ?
ㄴ 바로 headers 에 메타데이터를 보내서 확인한다.
이 메타 정보를 바로 Json web token 일명 `jwt` 라고 한다.
요청 1의 응답 1에서 200Ok와 token 발행
요청 2는 발행 받은 token과 함께 요청 보냄
JSON Web Token
위의 그림은 JWT구조입니다.
헤더에는
- 토큰 타입과 해시 알고리즘 정보가 들어간다.
- 헤더 내용은 base64 방식으로 인코딩해서 jwt의 가장 첫 부분에 기록된다.
- 개인정보가 들어가면 안된다.
내용(payload)
- 만료시간을 나타내는 exp와 같이 미리 정의된 집합인 Registered Claim
- 공개용 정보 전달을 목적으로 하는 Public Claim
- 그리고 클라이언트와 서버간 협의하에 사용하는 Private Claim
- 위의 세 가지 요소를 조합하여 작성한 뒤 BASE64 인코딩 하여 두번째 요소로 위치한다.
서명 (signature)
- jwt 가 원본 그대로라는 것을 확인할 때 사용하는 부분입니다.
- 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드입니다.
- 헤더(Header)와 페이로드(Payload)의 값을 각각 BASE64로 인코딩한다
- 그리고 인코딩한 값을 비밀 키를 이용해 헤더(Header)에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64로 인코딩하여 생성합니다.
JWT의 장점
- JWT 의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없습니다.
- 쿠키를 전달하지 않아도 되므로 쿠키를 사용함으로써 발생하는 취약점이 사라집니다.
- URL 파라미터와 헤더로 사용
- 트래픽 대한 부담이 낮음
- REST 서비스로 제공 가능
- 내장된 만료
- 독립적인 JWT
JWT의 단점
- Self-contained: 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있습니다.
- 토큰 길이: 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있습니다.
- Payload 인코딩: 페이로드(Payload) 자체는 암호화 된 것이 아니라, BASE64로 인코딩 된 것입니다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 합니다.
- Stateless: JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능합니다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 합니다.
- Tore Token: 토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 합니다.