토큰 기반 인증
사용자 인증 방법의 종류
- 서버 기반 인증
- 토큰 기반 인증
- 세션 기반 인증
세션 기반 인증
스프링 시큐리티에서 기본적으로 제공해주는 인증 방식. 사용자마다 사용자의 정보를 담은 세션을 생성하고 저장
토큰 기반 인증
토큰을 사용하는 방법. 토큰은 서버에서 클라이언트를 구분하기 위한 유일한 값인데 서버가 토큰을 생성해서 클라이언트에게 제공하면 클라이언트는 이 토큰을 가지고 있다가 여러 요청을 이 토큰과 함께 신청함
토큰을 전달하고 인증받는 과정
- 클라이언트가 아이디와 비밀번호를 서버에게 전달하면서 인증 요청
- 서버는 아이디와 비밀번호를 확인해서 유효한 사용자인지 검증. 유효한 사용자라면 토큰을 생성해서 응답
- 클라이언트는 서버에서 준 토큰을 저장
- 이후 인증이 필요한 api를 사용할 때 토큰을 함께 보냄
- 서버는 토큰이 유효한지 검증
- 토큰이 유효하다면 클라이언트가 요청한 내용을 처리함
토큰 기반 인증의 특징
1. 무상태성
사용자의 인증 정보가 담겨있는 토큰이 서버가 아닌 클라이언트에 있으므로 서버에 저장할 필요가 없다는 것.
서버에서 무언가를 가지고 있다는 건 그만큼 자원을 소비하고 있다는 건데 토큰 기반 인증에서는 클라이언트에서 인증 정보가 담긴 토큰을 생성하고 인증함
클라이언트에서 상태를 관리하면 서버 입장에서는 클라이언트의 인증 정보를 저장하거나 유지하지 않아도 되기때문에 완전한 무상태로 효율적인 검증을 할 수 있다.
💡 상태관리? 사용자의 인증 상태를 유지하면서 이후 요청을 처리하는 것
2. 확장성
서버를 확장할 때 상태 관리를 신경 쓸 필요가 없으니 서버 확장에도 용이함
예를들어 결제서버와 주문서버가 분리되어 있다고 가정하면 세션 인증 기반은 각각 api에서 인증을 해야되는 것과는 달리 토큰 기반 인증에서는 토큰을 가지는 주체는 서버가 아니라 클라이언트이기 때문에 가지고 있는 하나의 토큰으로결제 서버와 주문 서버에 요청을 보낼 수 있다. 어차피 토큰은 클라이언트가 가지고 있기 때문에 페이스북 로그인, 구글 로그인 같이 토큰 기반 인증을 사용하는 다른 시스템에 접근해 로그인 방식을 확장할 수도 있다
3. 무결성
토큰 방식은 HMAC 기법이라고도 부른다. 토큰을 발급한 이후에는 토큰 정보를 변경하는 행위를 할 수 없다. 즉, 토큰의 무결성이 보장된다.
JWT
JWT의 구조
- 헤더
- 내용
- 서명
헤더
토큰의 타입과 해싱 알고리즘을 지정하는 정보를 담고 있다.
- JWT 토큰, HS 256 해싱 알고리즘을 사용
{
"typ": "JWT",
"alg": "HS256"
}
내용
내용에는 토큰과 관련된 정보를 담는다. 내용의 한 덩어리를 클레임이라고 부르며 클레임은 키값의 한 쌍으로 이루어져 있다. 클레임은 공개 클레임, 비공개 클레임으로 나눌 수 있다.
이름 설명
iss | 토큰 발급자 |
sub | 토큰 제목 |
aud | 토큰 대상자 |
exp | 토큰의 만료시간, 시간은 NumericDate 형식으로 하며, 항상 현재시간 이후로 설정 |
nbf | 토큰의 활성 날짜와 비슷한 개념, nbf는 Not Before으 의미함. NumericDate 형식으로 날짜를 지정하며 이 날짜가 지나기 전까지는 토큰이 처리되지 않는다. |
iat | 토큰이 발급된 시간으로 lat은 issued at 을 의미함 |
jti | JWT의 고유 식별자로써 주로 일회용 토큰에 사용 |
공개 클레임과 비공개 클레임
공개 클레임은 공개되어도 상관 없는 클레임을 의미한다. 충돌을 방지할 수 잇는 이름을 가져야 하고 보통 클레임 이름은 URI로 짓는다.
비공개 클레임은 공개하면 안되는 클레임을 이야기한다. 클라이언트와 서버 간의 통신에 사용된다
{
"iss": "dev.rowoon@gmail.com", // 등록된 클레임
"iat": 16230948, // 등록된 클레임
"exp": 16330112, // 등록된 클레임
"https": //devrwoon.com/jwt_claims/is_admin": true, // 공개 클레임
"email": "dev.rowoon@gmail.com", // 비공개 클레임
"hello": "영국어론 할로" // 비공개 클레임
}
서명
해당 토큰이 조작되었거나 변경되지 않았음을 확인하는 용도 헤더의 인코딩 값고 내용의 인코딩 값을 합친 후에 주어진 비밀키를 사용해 해시값 생성
토큰 유효기간 - 리프레시 토큰
액세스 토큰과 별개의 토큰임. 사용자를 인증하기 위한 용도가 아닌 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급하기 위해 사용함
액세스 토큰의 유효 기간을 짧게 설정하고 리프레시 토큰의 유효 기간을 길게 설정하면 혹여나 액세스 토큰이 털리더라도 몇 분뒤에는 사용할 수 없으니까 더 안전!
토큰 기반 인증
사용자 인증 방법의 종류
- 서버 기반 인증
- 토큰 기반 인증
- 세션 기반 인증
세션 기반 인증
스프링 시큐리티에서 기본적으로 제공해주는 인증 방식. 사용자마다 사용자의 정보를 담은 세션을 생성하고 저장
토큰 기반 인증
토큰을 사용하는 방법. 토큰은 서버에서 클라이언트를 구분하기 위한 유일한 값인데 서버가 토큰을 생성해서 클라이언트에게 제공하면 클라이언트는 이 토큰을 가지고 있다가 여러 요청을 이 토큰과 함께 신청함
토큰을 전달하고 인증받는 과정
- 클라이언트가 아이디와 비밀번호를 서버에게 전달하면서 인증 요청
- 서버는 아이디와 비밀번호를 확인해서 유효한 사용자인지 검증. 유효한 사용자라면 토큰을 생성해서 응답
- 클라이언트는 서버에서 준 토큰을 저장
- 이후 인증이 필요한 api를 사용할 때 토큰을 함께 보냄
- 서버는 토큰이 유효한지 검증
- 토큰이 유효하다면 클라이언트가 요청한 내용을 처리함
토큰 기반 인증의 특징
1. 무상태성
사용자의 인증 정보가 담겨있는 토큰이 서버가 아닌 클라이언트에 있으므로 서버에 저장할 필요가 없다는 것.
서버에서 무언가를 가지고 있다는 건 그만큼 자원을 소비하고 있다는 건데 토큰 기반 인증에서는 클라이언트에서 인증 정보가 담긴 토큰을 생성하고 인증함
클라이언트에서 상태를 관리하면 서버 입장에서는 클라이언트의 인증 정보를 저장하거나 유지하지 않아도 되기때문에 완전한 무상태로 효율적인 검증을 할 수 있다.
💡 상태관리? 사용자의 인증 상태를 유지하면서 이후 요청을 처리하는 것
2. 확장성
서버를 확장할 때 상태 관리를 신경 쓸 필요가 없으니 서버 확장에도 용이함
예를들어 결제서버와 주문서버가 분리되어 있다고 가정하면 세션 인증 기반은 각각 api에서 인증을 해야되는 것과는 달리 토큰 기반 인증에서는 토큰을 가지는 주체는 서버가 아니라 클라이언트이기 때문에 가지고 있는 하나의 토큰으로결제 서버와 주문 서버에 요청을 보낼 수 있다. 어차피 토큰은 클라이언트가 가지고 있기 때문에 페이스북 로그인, 구글 로그인 같이 토큰 기반 인증을 사용하는 다른 시스템에 접근해 로그인 방식을 확장할 수도 있다
3. 무결성
토큰 방식은 HMAC 기법이라고도 부른다. 토큰을 발급한 이후에는 토큰 정보를 변경하는 행위를 할 수 없다. 즉, 토큰의 무결성이 보장된다.
JWT
JWT의 구조
- 헤더
- 내용
- 서명
헤더
토큰의 타입과 해싱 알고리즘을 지정하는 정보를 담고 있다.
- JWT 토큰, HS 256 해싱 알고리즘을 사용
{
"typ": "JWT",
"alg": "HS256"
}
내용
내용에는 토큰과 관련된 정보를 담는다. 내용의 한 덩어리를 클레임이라고 부르며 클레임은 키값의 한 쌍으로 이루어져 있다. 클레임은 공개 클레임, 비공개 클레임으로 나눌 수 있다.
이름 설명
iss | 토큰 발급자 |
sub | 토큰 제목 |
aud | 토큰 대상자 |
exp | 토큰의 만료시간, 시간은 NumericDate 형식으로 하며, 항상 현재시간 이후로 설정 |
nbf | 토큰의 활성 날짜와 비슷한 개념, nbf는 Not Before으 의미함. NumericDate 형식으로 날짜를 지정하며 이 날짜가 지나기 전까지는 토큰이 처리되지 않는다. |
iat | 토큰이 발급된 시간으로 lat은 issued at 을 의미함 |
jti | JWT의 고유 식별자로써 주로 일회용 토큰에 사용 |
공개 클레임과 비공개 클레임
공개 클레임은 공개되어도 상관 없는 클레임을 의미한다. 충돌을 방지할 수 잇는 이름을 가져야 하고 보통 클레임 이름은 URI로 짓는다.
비공개 클레임은 공개하면 안되는 클레임을 이야기한다. 클라이언트와 서버 간의 통신에 사용된다
{
"iss": "dev.rowoon@gmail.com", // 등록된 클레임
"iat": 16230948, // 등록된 클레임
"exp": 16330112, // 등록된 클레임
"https": //devrwoon.com/jwt_claims/is_admin": true, // 공개 클레임
"email": "dev.rowoon@gmail.com", // 비공개 클레임
"hello": "영국어론 할로" // 비공개 클레임
}
서명
해당 토큰이 조작되었거나 변경되지 않았음을 확인하는 용도 헤더의 인코딩 값고 내용의 인코딩 값을 합친 후에 주어진 비밀키를 사용해 해시값 생성
토큰 유효기간 - 리프레시 토큰
액세스 토큰과 별개의 토큰임. 사용자를 인증하기 위한 용도가 아닌 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급하기 위해 사용함
액세스 토큰의 유효 기간을 짧게 설정하고 리프레시 토큰의 유효 기간을 길게 설정하면 혹여나 액세스 토큰이 털리더라도 몇 분뒤에는 사용할 수 없으니까 더 안전!
'Spring, Spring boot' 카테고리의 다른 글
일정관리프로그램 만들어보기 (0) | 2024.03.05 |
---|---|
OAuth2 (0) | 2024.01.16 |
스프링 시큐리티 config (0) | 2024.01.10 |
템플릿엔진 - 타임리프 (0) | 2024.01.04 |
TIL (1) | 2024.01.03 |