사이드 프로젝트를 진행하며, 유저 인증과 권한에 대한 부분이 필요했습니다. 어떤 방법을 사용하면 좋을지 다양한 인증 방법에 대해 먼저 알아보겠습니다.

다양한 인증 방법

세션 기반 인증

세션 기반 인증은 서버 측에서 세션을 유지하고, 클라이언트에게 '세션 식별자'를 부여하여 인증을 관리합니다.

사용자가 로그인하면 서버에서 세션을 생성하고, 세션 ID를 클라이언트에게 제공합니다.

클라이언트는 이 세션 ID를 서버에 전송하여 인증을 유지하고, 서버는 이 ID를 사용해 세션 정보를 확인하고 인증 여부를 판단합니다.

단점 : 서버에서 세션을 유지해야 하므로, 서버의 부담이 크고 세션 저장소에 대한 관리가 필요합니다.

쿠키 기반 인증

쿠키 기반 인증은 클라이언트 측에 쿠키를 사용하여 인증을 처리하는 방식입니다.

로그인 시 서버는 클라이언트에게 쿠키를 전달합니다. 클라이언트는 쿠키를 저장하고, 이후 요청 시 서버에 쿠키를 포함해 전송하고 서버는쿠키를 확인하여 인증을 처리합니다.

단점 : 쿠키는 클라이언트 측에 저장되므로, 쿠키가 조작되거나 탈취의 가능성이 있습니다.
도메인 간 인증에 어려움이 있을 수 있습니다.

SAML

Security Assertsion Markup Language 는 XML 기반 프로토콜입니다. 주로 기업에서 사용되며, SSO 시스템에 적용됩니다.

단점 : 데이터 크기가 크고, 파싱 및 처리에 높은 리소스가 필요합니다.

OAuth

Oauth 는 제 3자 인증을 위한 프로토콜로, 사용자가 자신의 인증 정보를 다른 애플리케이션과 공유할 수 있도록 합니다.

OAuth를 사용하면 사용자는 자신의 인증 정보를 제공하고, 해당 서비스의 권한을 얻습니다.

단점 : 복잡한 구현이 필요하고, 기업 간의 표준화된 지원과 호환성이 필요합니다.

OpenID Connect

OpenID Connect 는 OAuth 2.0 위에 구축된 신뢰 가능한 인증 계층을 제공하는 표준 프로토콜입니다.

단점 : Oauth 와 동일한 문제가 있습니다.

JWT

JWT 는 클레임 기반의 토큰 인증 방식입니다. 경량화된 구조와 인코딩된 형식으로 데이터 전송에 효율적입니다. 표준화된 프로토콜로 다양한 언어와 프레임워크에서 지원됩니다.

단점 : 토큰을 발급한 후에는 유효기간이 만료될 때까지 사용되므로, 토큰의 유효기간을 적절하게 유지해야 합니다. 서명키가 노출되면 토큰이 위조될 수 있습니다.

여러 인증 방법이 있지만, JWT 방식이 표준으로 정의되었기 때문에, 여러 프레임워크에서 지원되고 있습니다.
또한 확장성에서 장점이 있는데 JWT는 토큰 자체에 사용자의 정보가 저장되어 있어있기 때문에 서버 입장에서 토큰을 검증만 해주면 됩니다. 서버에서 매번 세션이나 db를 조회하지 않아도 되기 때문에 인프라 비용을 감소시킬 수 있습니다.
그렇게 때문에 JWT를 선택을 하였고, JWT에 대해서 알아보도록 하겠습니다.

JWT

JSON Web Token 의 약자로 웹 애플리케이션 간에 정보를 안전하게 전송하기 위해 사용되는 인증 및 권한 부여 프로토콜입니다.

JWT는 JSON 형식으로 표현되며, 암호화되어 있어 안전하게 전달될 수 있습니다. 이 토큰은 서버와 클라이언트 간에 인증을 처리하고, 사용자의 권한을 확인하여 보안을 강화할 수 있습니다.

JWT 구성

JWT 는 크게 세파트로 나누어집니다.
aaaaaa.bbbbb.cccccc 이런식으로 나누어지며, 순서대로 header,payload,signature로 구성됩니다.

header

header 는 토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있습니다.
1. 토큰의 유형
2. 해시 알고리즘

payload

토큰을 담을 클레임 정보를 포함합니다. Payload에 담는 정보의 한 조각을 클레임이라고 부르고, 이는 name / value 의 한 쌍으로 이루어져 있습니다.

클레임은 여러개를 넣을 수도 있으며, registered, public, private 클레임 세 종류가 있습니다.

signature

signature는 헤더와 페이로드가 비밀키로 서명되어 저장됩니다.

프로젝트에서 사용되는 예시 토큰입니다. 붉은색 header, 보라색 payload, 파란색 signature 가 .을 사이에 두고 있습니다.

header를 확인하면, 알고리즘 종류가 있습니다.

payload를 확인해보면, 내용들이 key:value 형태로 들어가 있습니다.

Payload에서 자주 사용되는 JSON 키 이름은 다음과 같습니다.
sub 키: 인증 주체(subject)
iss 키: 토큰 발급처
typ 키: 토큰의 유형(type)
alg 키: 서명 알고리즘(algorithm)
iat 키: 발급 시각(issued at)
exp 키: 말료 시작(expiration time)
aud 키: 클라이언트(audience)

토큰 암호화키

JWT는 토큰을 생성할 때, 서명(Signature)를 추가하여 토큰의 무결성을 보장합니다. 서명을 생성하고 검증하기 위해서는 암호화 키가 필요합니다.

암호화키는 아래의 경우 필요합니다.

1. 토큰 생성 : 암호화키를 사용하여 토큰에 서명을 추가합니다. 이 서명은 토큰의 변조를 방지하고, 무결성을 검증합니다. 토큰을 발급하는 서버에서는 비밀키를 사용하여 서명을 생성합니다.

2. 토큰 검증 : 토큰의 유효성을 검증해 토큰이 변조되지 않았음을 확인합니다. 토큰 검증에는 발급된 토큰과 동일한 암호화키를 사용합니다.

3. 토큰 갱신 : 생성과 마찬가지로 갱신에도 사용됩니다.

토큰 암호화 키는 토큰 생성 및 검증을 위해 필요한 중요한 보안 자원이기 때문에,안전하게 관리합니다. 주로 암호화 알고리즘을 사용하고, 키 관리 시스템 또는 보안 모듈을 사용하여 저장합니다.

JWT 작동방식

사용자가 로그인을 시도하면 서버는 사용자의 인증 정보를 확인한 후 JWT를 발급합니다.

클라이언트는 이 JWT를 보관하고, 이후 서버에 요청을 보낼 때마다 JWT를 함께 전송합니다.

서버는 이 JWT를 복호화하고 유효성을 검증한 후 요청을 처리합니다.

JWT 의 한계

JWT는 사용자 인증 용도 정도로 사용됩니다. 그래서 현재 저희 회사에서는 JWT + session을 함께 사용하고 있습니다.
로그아웃 기능이나, 현재 로그인되어 있는 유저들에 대한 정보 등을 구현하기 위해서는 JWT 만 사용해서는 어렵기 때문입니다.

서명이 되어 있는 JWT 서버에서만 유효성을 검증할 수 있지만, 저장된 데이터는 위 사진처럼 누구나 열람이 가능합니다. 그래서 토큰에는 간단한 정보만 저장해야 안전합니다.