로그인 구현방식 2. 토큰 기반 인증방식

1. 개념

  • 인증은 토큰기반 인증 서버를 통해서 처리하고, 다른 컨텐츠를 주는 서버는 stateless 하게 하자는 이론이 담겨있다.

  • 여기서 토큰은 주로 JWT 토큰이 사용된다.

2. 과정

  1. 클라이언트는 로그인 정보를 인증서버로 보낸다.

  2. 인증서버에서는 클라이언트의 정보를 확인한 뒤, 토큰을 생성하여 전달한다.

    1. 토큰에는 accessToken, refreshToken 두 가지가 존재한다.

  3. 받은 토큰을 헤더값에 넣어 클라이언트는 다른 서버들에게 stateless 하게 요청한다.

3. JWT

  • Json Web Token 을 의미하며, json 객체로 인코딩되어 다음과 같은 이름이 붙었다.

  • 헤더, 페이로드, 서명 등 세 개의 파트로 구성되어있다.

    • header : 어떠한 서명 알고리즘을 사용할 것인지에 대한 정보

    • payload : 데이터, 토큰 발급자, 토큰 만료기간(유효기간),

    • signature : 헤더에 정의된 알고리즘으로 인코딩된 헤더값, 인코딩된 payload 값, 그리고 비밀키를 기반으로 생성된 서명값이다.

  • 메시지 인증이나 암호화에 사용된다.

  • 실습해보기

4. 장점과 단점

  • 장점

    • 사용자 인증에 필요한 값은 토큰에 담겨있으므로, 별도의 인증 저장소가 필요없다.

    • 다른 종류의 토큰 SAML(Security Assersion Markup Language Tokens) 과 비교해 보았을 때 경량화되어있다.

    • Json object 타입으로 인코딩 되어있기 때문에 직렬화, 역직렬화가 용이하다.

  • 단점

    • 토큰이 탈취당했을 경우, 디코딩하여 데이터를 볼 수 있다.

    • 토큰의 양이 커지면 서버에 과부하를 줄 수 있다.

5. 구현해보기

  • token 기반 인증방식은 2가지 토큰을 이용하여 이루어진다고 했다.

  • 클라이언트에서 서버로 로그인 정보를 보내면 서버는 accessToken, refreshToken 두 가지를 응답한다.

  • 바로 이 refreshToken 을 이용하여 accessToken 이 만료되기 전에 새로운 accessToken 값이 전달된다.

  • 따라서 보통 accessToken 은 유효 기간이 짧고, refreshToken 은 그것보다 조금 길다.

6. 주의할 점

OAuth2.0 과 JWT 에 관한 표준문서인 RFC 6750, RFC 7519 를 기반으로 보면, 아래와 같은 점들을 주의해야한다.

  1. 토큰값은 주로 Http Header 의 Authorization 혹은 Http Header 의 Cookie 에 담겨 요청되는데, 이때, value 값에는 "Bearer " 를 토큰 맨 앞에 붙여주어, 현재 토큰 기반으로 인증을 하고 있다는 것을 알려주어야 한다.

  2. Https 를 사용해야한다.

  3. 쿠키에 저장한다면, SameSite:Strict 설정을 추가해야한다.

  4. 토큰은 수명이 짧게 두어 보안을 높이는 것이 좋다.

  5. url 에 토큰을 전달해서는 안된다.

Last updated