3. 인증과 인가, 토큰과 세션

HTTP에서의 인증과 인가, 그리고 토큰 기반 인증 방식과 세션 기반 인증 방식에 대해 알아보겠다.

---

1. 서버와 통신하려면

서버는 사용자와 통신하기 위해선 사용자가 누구인지 알 필요가 있다.

그렇기에 대부분의 서비스는 처음에 사용자가 로그인하고, 그 이후 기능을 이용하도록 한다.

 

그러나 일반적으로 서버는 HTTP 프로토콜을 사용하며, HTTP 프로토콜은 Stateless(무상태성)로 동작한다.

 

1.1 Stateless

Stateless는 서버가 클라이언트를 기억하지 않는 특성이다.

정확히는, 이전에 요청을 보낸 적이 있는 클라이언트더라도 그 클라이언트가 누구인지 정보를 저장하지 않는다.

 

서비스의 규모가 조금이라도 커지면 하루에 접속하는 사용자 수가 만 단위를 호령한다.

서버가 이렇게 많은 클라이언트의 정보를 계속 기억하는 건 매우 큰 부담이기 때문에,

비교적 부담이 적도록 요청마다 클라이언트가 자신의 정보를 제시하도록 발전했다.

 

그렇기에 서버는 매 요청마다 클라이언트가 누구인지 식별하는 과정이 필요하다.

 

2. 인증과 인가

이 과정을 인증이라고 부르며, 인증된 정보를 바탕으로 클라이언트가 자원에 접근할 수 있도록 권한을 부여하는 과정을 인가라고 부른다.

 

여기서, 서버는 매 요청마다 인증을 수행하기 때문에

클라이언트 또한 요청마다 사용자의 ID, 비밀번호 등의 인증 정보를 제공해야 한다.

 

그러나 이 방식은 사용자가 계속 자신의 비밀번호를 입력하거나, 클라이언트가 암호화되지 않은 사용자의 평문 비밀번호를 기억하는 등 편의성 면에서도, 보안 면에서도 좋지 못하다.

 

이것을 해결하기 위해 클라이언트는 1회만 인증을 진행하고,

이것을 기반으로 발급된 임의의 인증 수단을 서버에게 요청마다 제시하는 방식을 고안해냈다.

 

3. 인증 수단

클라이언트가 한 번 로그인을 진행하면,

서버는 이 인증 기록을 증명하고

이후에 사용자가 자신의 정보를 입력하는 과정을 생략할 수 있도록

클라이언트의 인증 정보를 담은 임의의 인증 수단을 발급한다.

 

입구를 드나들 때마다 제시하는 키카드와 매우 유사하다.

 

3.1 인증 수단의 정보

이 인증 수단에는 여러 정보가 저장되는데,

데이터베이스에 저장된 사용자 정보를 식별할 수 있는 Key 값이라던가, 사용자 권한 정보 등이 포함된다.

 

3.2 인증 수단의 유효 기간

이 인증 수단은 제시만 하면 그 인증 정보를 인가받을 수 있다.

그렇기 때문에 악의를 가진 해커가 인증 수단을 탈취하면 사용자 정보를 마음대로 사용할 수 있게 된다.

이러한 약점을 보완하기 위해 인증 수단에는 유효 기간이 존재한다.

 

3.3 인증 수단의 종류

이 인증 수단에는 가장 널리 쓰이는 방식이 두 가지가 있다.

 

하나는 비교적 오래전부터 쓰여온 방식인 세션 기반 인증 방식,

하나는 비교적 최근에 개발된 토큰 기반 인증 방식이다.

 

4. 세션 기반 인증 방식

세션이란, 클라이언트와 서버 사이의 연결을 말한다.

보다 정확히, 서버가 클라이언트의 정보를 기억하며 논리적인 연결 상태를 유지한다.

클라이언트에서 서버의 정보를 저장하는 쿠키와 대응되는 개념이라고 볼 수 있다.

 

세션 기반 인증 방식이란,

서버가 클라이언트의 인증 수단인 세션을 저장하고,

클라이언트는 이 세션의 식별자인 세션 ID를 제시하는 방식이다.

세션 ID는 보통 쿠키를 이용해 전달된다.

 

그런데, 앞에서 클라이언트의 정보를 서버가 기억하고 있는 것은 큰 부담이라고 말했다.

여기서 저장되는 클라이언트 정보는 수명이 그다지 길지 않기에 조금이나마 부담을 덜어간다.

모든 클라이언트가 아닌, 짧은 유효 기간을 가진 세션이 유효한 동안만 저장한다.

 

그럼에도 여전히 서버의 부담이 존재해 이를 다시 한 번 개선하고자 토큰 기반 인증 방식이 고안되었다.

 

5. 토큰 기반 인증 방식

세션 기반 인증 방식과 다르게, 인증 수단을 완전히 클라이언트에서 저장한다.

 

여기서 클라이언트는 이 인증 수단을 얼마든지 위조할 수 있다.

이를 방지하기 위해 토큰 문자열을 암호화하거나,

토큰 자체의 유효성을 확보하기 위해 서명 등을 진행한다.

 

그리고 가장 많이 쓰이는 토큰 종류로 JSON Web Token, JWT가 존재한다.

 

6. JWT

JWT는 현재 가장 많이 쓰이는 토큰 방식으로, 인증 정보가 JSON 형식으로 구성된 토큰이다.

6.1 JWT 구조

Header, Payload, Signature 세 부분으로 구분된다.

6.1.1 Header

서명 부분인 Signature의 암호화 방식과 이 토큰이 JWT임을 명시한다.

 

6.1.2 Payload

사용자의 인증 정보를 담는 부분이다.

 

6.1.3 Signature

토큰의 위조를 방지하기 위한 서명 부분이다.

Header와 Payload, 그리고 암호화에서 사용되는 시크릿 키를 합쳐,

Header에서 명시된 암호화 방식으로 암호화한 문자열이다.

 

6.1.4 상세 구조

 

아래는 예시 토큰으로, 각 부분이 .으로 구분되어 있으며, 이는 Base64로 인코딩되어 있다.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkYXlicmVhazMxMiIsIm5hbWUiOiJEYXlicmVhayIsImlhdCI6MTUxNjIzOTAyMn0.A9PaecQWOnbScCqJno8y8jKWVXqNNYosz90hrezs3iU

 

Header와 Payload를 디코딩해서 추출해보면,

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

{
	"sub":"daybreak312",
	"name":"Daybreak",
	"iat":1516239022
}

 

 

Base64는 단순히 ASCII 문자를 영어 대소문자 영역으로 제한해서 다시 작성한다.

그렇기에 변조가 쉬워 서명 부분은 보통의 경우 강력한 단방향 해싱 암호화 알고리즘인 HS256을 통해 인코딩된다.

굳이 전체를 HS256으로 암호화하지 않는 이유는, 서버가 Payload를 읽을 수 있어야 하기 때문이다.

 

HS256이란

가장 강력하다 알려진 단방향 해싱 알고리즘이다.

한 번 암호화된 문자열을 다시 복호화하는 것은 현재 기술력으로 불가능에 가깝다.

무작위 대입(브루트 포스)으로 원본을 알아내려해도 매우 많은 시간을 들여야 한다.

 

6.2 Access Token, Refresh Token

인증 수단의 유효 기간이 길면, 그만큼 탈취 시 공격 가능 시간이 길어진다.

그렇기 때문에 토큰은, 실제로 인증에서 사용되는 유효 기간이 짧은 Access Token과,

토큰을 재발급할 때 사용되는 유효 기간이 긴 Refresh Token 두 개를 운용하는 경우가 많다.

 

 

Access Token은 오로지 인증에서만 사용되는 토큰으로, 원래의 토큰과 그 의도가 같다.

 

Refresh Token은 이미 인증했으나 그 인증의 기한이 의도적으로 짧아 만료된 사용자에게, 다시 로그인해야하는 번거로움을 생략하기 위한 토큰이다.

Access Token을 재발급하기 위한 토큰이다.

 

6.2.1 RTR, Refresh Token Rotation

Refresh Token의 유효 기간이 길며, 이를 재사용 가능할 경우 결국 Access Token의 유효 기간이 긴 것과 같으며,

Refresh Token 방식과 유효 기간을 의도적으로 짧게 한 보안 정책이 모두 무효해진다.

 

이를 한 번 더 보완하고자 고안된 방식이 RTR, Refresh Token Rotation이다.

한 번 Refresh Token을 사용 Access Token과 같이 Refresh Token도 함께 재발급해주고,

이전의 Access Token, Refresh Token을 모두 무효화하는 정책이다.

---

글을 읽는 이들에게 도움이 되었길 바라며, 이상으로 글을 마치도록 하겠다.