Token 인증방식, access token, refresh Token

 

 

Token 인증

토큰 기반 인증 시스템은 클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여.

이 토큰은 유일하며 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 심어서 보낸다.

그럼 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과 일치 여부를 체크하여 인증 과정을 처리.

인증받은 사용자에게 토큰을 발급하고, 로그인이 필요한 작업일 경우 헤더에 토큰을 함께 보내 인증받은 사용자인지 확인하기 때문에

서버 기반 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless한 특징을 가지고 있다.

 

 

 

Token 인증방식

1. 사용자가 아이디와 비밀번호로 로그인 함.

2. 서버 측에서 사용자(클라이언트)에게 유일한 토큰을 발급.

3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해두고,
    서버에 요청할 때마다 해당 토큰을 SHHTTP 요청 헤더에 포함시켜 전달.

4. 서버는 전달받은 토큰을 검증하고 요청에 응답.
    토큰에는 요청한 사람의 정보가 담겨있기에 서버는 DB를 조회하지 않고 누가 요청하는지 앎.

 

 

 

 

Token 인증방식 문제점

Access Token만을 통한 인증 방식의 문제는 

만일 제 3자에게 탈취당할 경우 보안에 취약하다는 점이다.

 

Access Token은 발급된 이후, 서버에 저장되지 않고 토큰 자체로 검증을 하여 사용자 권한을 인증하기 때문에,

Access Token이 탈취되면 토큰이 만료되기 전 까지, 토큰을 획득한 사람은 누구나 권한 접근이 가능해 지기 때문이다.

 

큰 유효기간을 짧게하면 토큰 남용을 방지하는 것이 해결책이 될 수 있지만, 

유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다는 단점이 있다. 

그렇다고 무턱대고 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 된다.

 

 유효기간을 짧게 하면서 좋은 방법은 Refresh Token이다.

Access Token은 접근에 관여하는 토큰이고, 

Refresh Token은 재발급에 관여하는 토큰 이므로 행하는 역할이 다르다고 보면 된다.

 

Refresh Token은 긴 유효기간을 가지면서,

Access Token이 만료됐을 때 새로 재발급해주는 열쇠가 된다.

만일 만료된 Access Token을 서버에 보내면, 서버는 같이 보내진 Refresh Token을  DB에 있는 것과

비교해서 일치하면 다시 Access Token을 재발급하는 간단한 원리이다.

그리고 사용자가 로그아웃을 하면 저장소에서 Refresh Token을 삭제하여 사용이 불가능하도록 하고

새로 로그인하면 서버에서 다시 재발급해서 DB에 저장한다.

 

 

 

 

 

Acess Token만을 이용한 서버 인증 방식

1. 사용자가 로그인을 합니다.
2. 서버에서 사용자 확인 후, Access Token(JWT)에 권한 인증을 위한 정보를 Payload에 넣고 생성합니다.
3. 생성한 토큰을 클라이언트에게 반환하고, 클라이언트는 이 토큰을 저장합니다.
4. 클라이언트는 권한 인증이 필요한 요청을 할 때마다 이 토큰을 헤더에 실어 보냅니다.
5. 서버는 헤더의 토큰을 검증하고, Payload의 값을 디코딩하여 사용자의 권한을 확인하고 데이터를 반환합니다.
6. 만약, 토큰이 valid하지 않거나 만료되었다면 새로 로그인을하여 토큰을 발급받아야합니다.

 

 

 

 

 

Access / Refresh Token 재발급 원리

Refresh Token만 서버측의 DB에 저장하며,

Refresh Token과 Access Token을 쿠키 혹은 웹스토리지에 저장한다.

 

1. access token과 refresh token 모두가 만료된 경우 > 에러 발생 (재 로그인하여 둘다 새로 발급)

2. access token은 만료됐지만, refresh token은 유효한 경우 >  refresh token을 검증하여 access token 재발급

(클라이언트(쿠키, 웹스토리지)에 저장되어있는 refresh token과 서버 DB에 저장되어있는 refresh token 일치성을 확인한 뒤 access token 재발급한다.)

3. access token은 유효하지만, refresh token은 만료된 경우 >  access token을 검증하여 refresh token 재발급

(access token이 유효하다라는 것은 이미 인증된 것과 마찬가지니 바로 refresh token 재발급한다.)

4. access token과 refresh token 모두가 유효한 경우 > 정상 처리

 

 

로그아웃을 하면 Access Token과 Refresh Token을 모두 만료시킨다.

 

 

Refresh Token 인증과정

1. 사용자가 ID , PW를 통해 로그인.

2. 서버에서는 회원 DB에서 값을 비교

3~4. 로그인이 완료되면 Access Token, Refresh Token을 발급한다. 이때 회원DB에도 Refresh Token을 저장해둔다.

5. 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보낸다.

6~7. Access Token을 검증하여 이에 맞는 데이터를 보낸다.

8. 시간이 지나 Access Token이 만료됐다.

9. 사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보낸다.

10~11. 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보낸다.

12. 사용자는 Refresh Token과 Access Token을 함께 서버로 보낸다.

13. 서버는 받은 Access Token이 조작되지 않았는지 확인한 후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교한다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해준다.

14. 서버는 새로운 Access Token을 헤더에 실어 다시 API 요청 응답을 진행한다.