[인증/보안] Token

Hashing

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

🔗해싱해보기

솔트란? 

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

해싱의 목적?

- 왜 복호화가 불가능한 암호화 방식 사용? 데이터 그 자체 사용하는 것이 아니라 동일한 데이터를 사용하고 있는지만 체크하기 때문

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

---

Token

토큰을 사용하면 사용자의 인증 정보를 서버가 아닌 클라이언트 측에 저장할 수 있다.

 

세션 기반 인증의 한계?

- 세션 기반 인증은 서버에서 유저의 상태를 관리해서 서버의 부담이 크기때문에 이를 줄이기 위해 클라이언트에 유저 정보를 저장해서 서버의 부하나 메모리 부족문제를 줄일 수 있는 토큰 기반 인증 방식 등장

- 웹 보안에서의 토큰은 현실의 사무실 출입증, 승차권처럼 인증과 권한 정보를 담고 있는 암호화된 문자열

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

 

토큰 인증 방식의 흐름

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

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

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

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

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

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

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

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

 

토큰 인증 방식 장점?

무상태성 : 서버는 비밀 키를 통해 클라이언트가 보낸 토큰의 유효성만 검증하면 돼서 무상태적인 아키텍쳐 구축 할 수 있다.

확장성 : 다수의 서버가 공통된 세션 데이터를 가질 필요 없다.

어디서나 토큰 생성 가능 : 토큰 생성과 검증이 하나의 서버에서 이루어지지 않아도 되기 때문에 생성만 담당하는 서버 구축해서 여러 서비스 간의 공통된 인증 서버 구현 가능

권한 부여에 용이 : 다양한 정보를 담을 수 있다.

 

JWT(JSON Web Token)

JSON 객체에 정보를 담고 이를 토큰으로 암호화하여 전송할 수 있는 기술

 

구성

dot(.) 으로 나누어진 세부분 Header, Playload, Signature

 

Header : 해당 토큰 자체를 설명하는 데이터

- 토큰 종류나타내는 typ

- 어떤 알고리즘으로 signature를 암호화 했는지 알 수 있는 alg

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

Playload : 전달하려는 내용물을 담고있는 부분

- 단순한 Base64로만 인코딩 된 값

- 브라우저에서 쉽게 디코딩하여 값을 읽을 수 있으므로 민감한 정보 담지 않는것이 좋다.

ex) 유저의 개인정보, 토큰의 발급 시간 및 만료 시간

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

Signature : 토큰의 무결성 확인할 수 있는 부분 

- Base64로 인코딩된 Header와 Payload + 시크릿 값 합쳐 Header에 표시한 알고리즘으로 암호화 한 값

- 만약 HMAC SHA256알고리즘을 사용했다면 아래와 같다.

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

이러한 토큰도 한계가 있다...?

- 서버가 관리 주체가 아니기 때문에(무상태성) 탈취되어도 강제로 만료 시킬 수 없다.

- 탈취를 막자고 유효기간 짧게 설정하면 만료될때마다 인증해야하고 길게하면 탈취되었을때 더 치명적임

- 토큰에 여러정보 넣을 수 있어서 크기가 커지면 암호화하는 과정도 길어지고 네트워크 비용문제 생길 수 있다.

 

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

한계를 극복하기 위해 고안된 방법들

- 액세스 토큰 : 서버에 접근하기 위한 토큰 보안을 위해 24시간 정도의 짧은 유효기간 설정

- 리프레시 토큰 : 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰 (액세스보다 유효기간 길게 설정)

그러나

리프레시 토큰의 유효기간을 길게 성정해준 만큼  탈취되었을때 위험성이 크다.

 

마무리

보안에 완벽이란 없다. 으-<-<