Token

해싱 (Hashing) 

➡️ 가장 많이 쓰이는 암호화 방식 중 하나. 복호화가 가능한 다른 암호화 방식들과 달리 해싱은 암호화만 가능

해시 함수(Hash Function)를 사용하여 암호화를 진행

• 항상 같은 길이 문자열을 리턴
• 서로 다른 문자열에 동일한 해시 함수를 사용하면 반드시 다른 결과값이 나옴
• 동일한 문자열에 동일한 해시 함수를 사용하면 항상 같은 결과 값이 나옴

비밀번호	해시 함수 (SHA1) 리턴 값
'password'	‘5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8’
'Password'	‘8BE3C943B1609FFFBFC51AAD666D0A04ADF83C9D’
'kimcoding'	‘61D17C8312E8BC24D126BE182BC674704F954C5A’

 

 

레인보우 테이블과 솔트 (Salt)

➡️ 항상 같은 결과 값이 나온다는 특성을 이용해 해시 함수를 거치기 이전의 값을 알아낼 수 있도록 기록해 놓은 표인 레인보우 테이블이 존재함. 레인보우 테이블에 기록된 값으 경우 유출이 되었을 때 해싱을 했더라도 해싱 이전의 값을 알아낼 수 있으므로 보안상 위협이 됨.

솔트는 소금이라는 뜻으로 말 소금을 치듯 해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 어렵게 만드는 방법

비밀번호 + 솔트	해시 함수(SHA1) 리턴 값
‘password’ + ‘salt’	‘C88E9C67041A74E0357BEFDFF93F87DDE0904214’
‘Password’ + ‘salt’	‘38A8FDE622C0CF723934BA7138A72BEACCFC69D4’
‘kimcoding’ + ‘salt’	‘8607976121653D418DDA5F6379EB0324CA8618E6’

 

해싱의 목적

➡️ 데이터 그 자체를 사용하는 것이 아닌 동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이 목적

민감함 데이터를 다루어야 하는 상황에서 데이터 유출의 위험성은 줄이면서 데이터의 유효성을 검증하기 위해서 사용되는 단방향 암호화 방식

 

---

토큰 인증 방식

토큰 인증 방식은 최근 웹 애플리케이션에서 많이 사용되는 인증 방식 중 하나이다. 토큰을 사용하면 사용자의 인증 정보를 서버가 아닌 클라이언트측에 저장할 수 있다.

 

 

토큰 인증 방식의 등장 배경

토큰 기반 인증은 기존의 세션 기반 인증이 가지고 있던 한계를 극복하고자 고안됨. 서버의 부담을 줄이기 위해 클라이언트에 이를 저장하는 방법인 토큰 기반 인증 방식이 등장했고 유저의 인증 상태를 클라이언트에 저장할 수 있어서 세션 인증방식의 비교해 서버의 부하나 메모리 부족 문제를 줄일 수 있음

 

 

토큰 인증 방식의 흐름

 

 

토큰 인증 방식의 장점

• 무상태성 : 서버가 유저의 인증 상태를 관리하지 않음. 서버는 비밀 키를 통해 클라이언트에서 보낸 토큰의 유효성만 검증하면 되기 때문에 무상태적인 아키텍처 구축
• 확장성 : 다수의 서버가 공통된 세션 데이터를 가질 필요가 없다는 것도 토큰 기반 인증의 장점. 서버확장 용이
• 어디서나 토큰 생성 가능 : 토큰의 생성과 검증이 하나의 서버에서 이루어지지 않아도 되기 때문에 토큰 생성만을 담당하는 서버를 구축할 수 있으며 여러 서비스간의 공통된 인증 서버를 구현
• 권한 부여에 용이 : 토큰은 인증 상태, 접근 권한 등 다양한 정보를 담을 수 있기 때문에 사용자 권한 부여에 용이. 어드민 권한 부여 및 정보에 접근할 수 있는 범위 설정 가능

 

JWT (JSON Web Token)

➡️ 토큰 기반 인증 구현 시 대표적으로 사용하는 기술. JSON 객체에 정보를 담고 이를 토큰으로 암호화하여 전송. 클라이언트가 서버에 요청을 보낼 때, 인증정보를 암호화된 JWT 토큰으로 제공하며 서버는 이 토큰을 검증하여 인증정보를 확인

 

 

JWT의 구성

. 으로 나누어진 세 부분이 존재하며 각각을 Header, Payload, Signature라고 함

• Header : HTTP의 헤더처럼 해당 토큰 자체를 설명하는 데이터가 담겨있음. 토큰의 종류, 시그니처를 만들 때 사용할 알고리즘을 JSON 형태로 작성

{
  "alg": "HS256",
  "typ": "JWT"
}

• Payload : HTTP의 페이로드와 마찬가지로 전달하려는 내용물을 담고있음. 어떤 정보에 접근 가능한지에 대한 권한, 유저의 이름과 같은 개인정보, 토큰의 발급 시간 및 만료 시간등 정보를 JSON 형태로 담음

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

• Signatur : 토큰의 무결성을 확인할 수 있음. Header와 Payload가 완성되면 이를 서버의 비밀키(암호화에 추가할 salt)와 Header에 지정한 알고리즘을 사용하여 해싱

HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

 

 

토큰 인증 방식의 한계

➡️ Signature를 사용해서 위조된 토큰을 알아낼 수는 있지만 토큰 자체가 탈취된다면 토큰 인증 방식의 한계가 드러남

• 무상태성 : 인증 상태를 관리하는 주체가 서버가 아니라 탈취되어도 해당 토큰을 강제로 만료시킬 수 없다. 토큰이 만료될 때까지 사용자로 가장해 계속해서 요청을 보낼 수 있음
• 유효기간 : 토큰이 탈취되는 상황을 대비해서 유효 기간을 짧게 설정하면 만료될 때마다 로그인해야 하기 때문에 좋지 않은 사용자 경험을 하게 됨. 길게 설정하면 토큰 탈취로 치명적임
• 토큰의 크기 : 여러 정보를 담을 수 있는 만큼 많은 데이터를 담으면 그만큼 암호화가 길어지고 토큰의 크기도 커져 네트워크 비용 문제 발생

 

액세스 토큰(Access Token)과 리프레시 토큰(Refresh Token)

➡️ 토큰 인증 한계를 극복하기 위해 다양한 방법들이 고안되었지만 대표적인 구현 방법은 액세스 토큰과 리프레시 토큰을 함께 사용

• Access Token : 서버에 접근하기 위한 토큰으로 토큰과 비슷한 역할을 함. 24시간 정도의 짧은 유효기간 설정
• Refresh Token : 액세스 토큰이 만료 되었을 때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰. 액세스 토큰보다 긴 유효기간 설정