해싱(Hashing)과 토큰(Token) 인증 방식

*  세션 인증 방식을 보완한 토큰 인증 방식
*  대표적인 토큰 인증 방식 JWT
-  JWT가 사용자의 정보를 암호화하여 토큰을 저장하는 방법

 

해싱 (Hashing)

 

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

해싱은 해시 함수(Hash Function)를 사용하여 암호화를 진행하는데, 해시 함수는 다음과 같은 특징을 가진다.

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

아래 표는 대표적인 해시 함수중 하나인 SHA1에 특정 입력 값을 넣었을 때 어떤 결과가 리턴되는지 보여주는 예시이다.

• 이 링크에서 SHA1 함수를 직접 사용해 볼 수도 있습니다.

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

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

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

[사진] 레인보우 테이블 예시

이때 활용할 수 있는 것이 솔트(Salt)이다.

• 솔트는 소금이라는 뜻으로,
• 말 그대로 소금을 치듯 해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도 해싱 이전의 값을 알아내기 더욱 어렵게 만드는 방법이다.
• 솔트를 사용하게 되면 해싱 값이 유출되더라도, 솔트가 함께 유출된 것이 아니라면 암호화 이전의 값을 알아내는 것은 불가능에 가깝다.

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

 

해싱의 목적

그런데, 왜 복호화가 불가능한 암호화 방식을 사용하는 걸까?

• 바로 해싱의 목적은 데이터 그 자체를 사용하는 것이 아니라, 동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이 목적이기 때문이다.
• 예시를 들어보면, 사이트 관리자는 사용자의 비밀번호를 알고 있을 필요가 없다.
  • 오히려 사용자들의 비밀번호를 알고 있다면, 이를 얼마든지 악용할 수 있기 때문에 심각한 문제가 생길 수도 있다.
  • 그래서 보통 비밀번호를 데이터베이스에 저장할 때, 복호화가 불가능하도록 해싱하여 저장하게 된다.
  • 해싱은 복호화가 불가능하므로 사이트 관리자도 정확한 비밀번호를 알 수 없다.
• 그럼 서버 측에서 비밀번호를 모르는 상태에서 어떻게 로그인 요청을 처리할 수 있는 걸까?
  • 해싱한 값끼리 비교해서 일치하는지 확인하면 된다.
  • 꼭 정확한 값을 몰라도, 해싱한 값이 일치한다면 정확한 비밀번호를 입력했다는 뜻이 되기 때문에, 해싱 값으로만 로그인 요청을 처리하는 데에도 전혀 문제가 없다.

 

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

• 비밀번호와 같은 사용자의 민감한 정보는 데이터베이스에 평문으로 저장하면 안 된다.
• 보통 클라이언트에서 HTTPS를 이용해 사용자의 비밀번호가 중간에 탈취되지 않도록 주의하고
• 서버는 요청으로 받은 비밀번호를 그대로 데이터베이스에 저장하지 않고 해싱(암호화)과정을 거친 뒤 저장한다.

 

토큰 인증 방식

 

토큰 인증 방식은 최근 웹 애플리케이션에서 많이 사용되는 인증 방식 중 하나이다. 

• 세션 인증 방식과 달리 토큰 인증 방식은 사용자의 인증 정보를 서버에 저장하지 않고 클라이언트에 저장한다.
• 이때 서버의 비밀키로 암호화하여 데이터를 서명하기 때문에 중간에서 토큰이 조작되더라도 서버가 이를 감지할 수 있다.
• 또한 세션 인증 방식처럼 아이디를 매번 검증해 대응하는 세션 객체를 찾을 필요가 없기 때문에 상대적으로 서버에 부담이 덜 가게 된다.

 

토큰 인증 방식의 등장 배경

토큰 기반 인증은 기존의 세션 기반 인증이 가지고 있던 한계를 극복하고자 고안되었다.

• 세션 기반 인증은 서버에서 유저의 상태를 관리한다.
• 그래서 개발자들은 서버의 부담을 줄이기 위해 서버가 사용자의 인증 상태를 저장하는 것이 아닌 클라이언트에 이를 저장하는 방법을 고민하게 되었고, 그 결과 토큰 기반 인증 방식이 등장하였다.
• 토큰은 유저의 인증 상태를 클라이언트에 저장할 수 있어서, 세션 인증 방식의 비교해 서버의 부하나 메모리 부족 문제를 줄일 수 있다.

 

 

 

토큰은 교통 승차권과 같이 무언가를 이용할 수 있는 권한이나 자격을 나타내는, 일종의 증표이다.

• 화폐를 대신하여 사용할 수 있는 물리적 형태의 징표로, 상품 구매나 서비스 사용에 대한 권한 및 자격을 제공한다.
• 일상생활에서 흔히 접하는 지하철 승차권 혹은 사무실 출입 카드가 토큰에 해당한다.

 

웹 보안에서의 토큰은 인증(Authentication)과 권한 정보(Authorization)를 담고 있는 암호화된 문자열을 말한다.

• 이를 이용해 특정 애플리케이션에 대한 사용자의 접근 권한을 부여할 수 있다.

토큰 인증 방식의 흐름

 

 

1. 사용자가 인증 정보를 담아 서버에 로그인 요청을 보낸다.

2. 서버는 데이터베이스에 저장된 사용자의 인증 정보를 확인한다.

3. 인증에 성공했다면 해당 사용자의 인증 및 권한 정보를 서버의 비밀 키와 함께 토큰으로 암호화한다.

4. 생성된 토큰을 클라이언트로 전달한다.

• HTTP 상에서 인증 토큰을 보내기 위해 사용하는 헤더인 Authorization 헤더를 사용하거나,
• 쿠키로 전달하는 등의 방법을 사용한다. 쿠키는 크기 제한이 있어 보통 Authorization헤더를 사용한다.

5. 클라이언트는 전달받은 토큰을 저장한다.

• 저장하는 위치는 Local Storage, Session Storage, Cookie 등 다양하다.

6. 클라이언트가 서버로 리소스를 요청할 때 토큰을 함께 전달한다.

• 토큰을 보낼 때에도 Authorization 헤더를 사용하거나 쿠키로 전달할 수 있다.

7. 서버는 전달받은 토큰을 서버의 비밀 키를 통해 검증한다.

• 이를 통해 토큰이 위조되었는지 혹은 토큰의 유효 기간이 지나지 않았는지 등을 확인할 수 있다.

8. 토큰이 유효하다면 클라이언트의 요청에 대한 응답 데이터를 전송한다.

토큰 인증 방식의 장점

 

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

JWT (JSON Web Token)

 

 

토큰 기반 인증 구현 시 대표적으로 사용하는 기술로 JWT(JSON Web Token)가 있다.

• 데이터 전송에 사용하는 토큰 기반 인증 기술이다.
• JWT는 JSON 객체에 정보를 담고 이를 토큰으로 암호화(서명)하여 전송할 수 있는 기술이다.
• 클라이언트가 서버에 요청을 보낼 때, 인증정보를 암호화된 JWT 토큰으로 제공하고, 서버는 이 토큰을 검증하여 인증정보를 확인할 수 있다.

JWT의 구성

JWT는 다음 그림과 같이 .으로 나누어진 세 부분이 존재하며 각각을 Header, Payload, Signature라고 부른다.

 

 

1. Header

Header에는 마치 HTTP의 헤더처럼 해당 토큰 자체를 설명하는 데이터가 담겨 있다.

• 토큰의 종류, 그리고 시그니처를 만들 때 사용할 알고리즘을 JSON 형태로 작성한다.
• Header에는 어떤 종류의 토큰인지 나타내는 typ과 어떤 알고리즘으로 Signature를 암호화했는지 알 수 있는 alg가 있다.

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

 

이 JSON 객체를 base64 방식으로 인코딩하면 JWT의 첫 번째 부분인 Header가 완성된다.

• 참고로, base64 방식은 원한다면 얼마든지 디코딩할 수 있는 인코딩 방식이다.
• 따라서 비밀번호와 같이 노출되어서는 안 되는 민감한 정보를 담지 않도록 해야 한다.
• 다음 링크에서 직접 사용해 볼 수도 있다. (링크)

2. Payload

Payload는 HTTP의 페이로드와 마찬가지로 전달하려는 내용물을 담고 있는 부분이다.

• 어떤 정보에 접근 가능한지에 대한 권한, 유저의 이름과 같은 개인정보, 토큰의 발급 시간 및 만료 시간 등의 정보들을 JSON 형태로 담는다.

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

 

이 JSON 객체를 base64로 인코딩하면 JWT의 두 번째 부분인 Payload가 완성된다.

• Payload는 단순한 Base64로만 인코딩된 값이다. 
• 따라서 브라우저에서도 이를 쉽게 디코딩하여 Payload의 값을 읽을 수 있다.
• 따라서 민감한 유저의 정보는 담지 않는 것이 좋다.

3. Signature

Signature는 토큰의 무결성을 확인할 수 있는 부분이다.

• Header와 Payload가 완성되었다면, Signature는 이를 서버의 비밀 키(암호화에 추가할 salt)와 Header에서 지정한 알고리즘을 사용하여 해싱한다.
• 예를 들어, 만약 HMAC SHA256 알고리즘을 사용한다면 Signature는 아래와 같은 방식으로 생성된다.
• Signature는 Base64로 인코딩된 Header와 Payload 그리고 시크릿 값을 합쳐 Header에 표시한 알고리즘으로 암호화한 값이다.

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

 

따라서 누군가 권한을 속이기 위해 토큰의 Payload를 변조하는 등의 시도를 하더라도 토큰을 발급할 때 사용한 Secret을 정확하게 알고 있지 못한다면 유효한 Signature를 만들어낼 수 없기 때문에 서버는 Signature를 검증하는 단계에서 위조 등의 올바르지 않은 토큰임을 알아낼 수 있다.

 

토큰 인증 방식의 한계

 

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

 

무상태성

인증 상태를 관리하는 주체가 서버가 아니므로, 토큰이 탈취되어도 해당 토큰을 강제로 만료시킬 수 없다.

• 따라서 토큰이 만료될 때까지 사용자로 가장해 계속해서 요청을 보낼 수 있다.
• 온라인 강의 , ott 서비스처럼 동시 접속을 막거나 디바이스를 강제로 로그아웃하는 기능이 필요한 경우 세션기반 인증이 적절하다.

 

유효 기간

발급된 토큰의 값 수정이나 강제 만료가 불가능하기 때문에 토큰이 탈취되는 상황을 대비해서 유효 기간을 짧게 설정하면, 사용자는 토큰이 만료될 때마다 다시 로그인을 진행해야 하기 때문에 좋지 않은 사용자 경험을 제공한다. 그렇다고 유효 기간을 길게 설정하면 토큰이 탈취될 경우 더 치명적으로 작용할 수 있다.

 

토큰의 크기

토큰에 여러 정보를 담을 수 있는 만큼, 페이로드에 많은 데이터를 담으면 그만큼 암호화하는 과정도 길어지고 토큰의 크기도 커지기 때문에 네트워크 비용 문제가 생길 수 있다.

액세스 토큰 & 리프레시 토큰

: Access Token & Refresh Token

 

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

 

Access Token

액세스 토큰은 말 그대로 서버에 접근하기 위한 토큰으로 앞서 다룬 토큰과 비슷한 역할을 한다.

• 사용자가 서버 리소스에 접근할 수 있도록 접근 권한을 제공하는 토큰이다.
• 따라서 보안을 위해 보통 24시간 정도의 짧은 유효기간이 설정되어 있다.

 

Refresh Token

리프레시 토큰은 서버 접근을 위한 토큰이 아닌 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰이다.

• 따라서 리프레시 토큰은 액세스 토큰보다 긴 유효기간을 설정한다.
• 토큰의 짧은 만료 주기로 인해 발생되는 사용자 경험 하락을 막기 위해 고안된 토큰이다.
• 사용자는 재로그인없이 지속된 인증상태를 유지할 수 있게 된다.

 

 

이렇게 두 가지의 각기 다른 토큰을 사용하는 경우, 액세스 토큰이 만료되더라도 리프레시 토큰의 유효기간이 남아있다면 사용자는 다시 로그인을 할 필요 없이 지속해서 인증 상태를 유지할 수 있다.

 

물론 리프레시 토큰의 도입도 모든 문제를 해결해주진 않는다.

• 리프레시 토큰은 긴 유효 기간을 가지고 있어 해당 토큰마저 탈취된다면 토큰의 긴 유효 기간 동안 악의적인 유저가 계속해서 액세스 토큰을 생성하고 사용자의 정보를 해킹할 수도 있기 때문이다.
• 이를 대비하기 위해 리프레시 토큰을 세션처럼 서버에 저장하고 이에 대한 상태를 관리하기도 한다.

 

---

 

결국 서버에서 상태를 관리하지 않기 위해 고안된 토큰 인증도 보안성을 위해 일정 부분 서버에서 상태 관리를 담당하는 것처럼 결국 이 세상에 완벽한 보안 방법은 없다. 세션, 토큰 등 다양한 보안 방식 및 여러 구현 방법들은 단순히 보안뿐만 아니라 보안과 사용자 경험 사이의 적절한 균형을 찾기 위해 만들어졌다.

 

따라서 개발자로서 내가 구현하려는 서비스에 어떤 인증 방식이 가장 적절한지 판단하고 의사결정 할 줄 아는 것이 가장 중요하다.