TIL-211228

Token-based Authentication

• 토큰 기반 인증

  • 세션 기반 인증: 서버에(혹은 DB) 유저 정보를 담는 인증 방식
    • 확인이 필요할 때마다 DB 또는 서버에 요청하여 세션값을 확인해야 함
    • 서버에 부담이 가고, 번거롭기도 함

• 클라이언트에 인증 정보를 보관하는 방법으로 토큰 기반 인증이 고안됨

  • 유저의 정보를 암호화한 상태로 토큰에 담아 클라이언트에 저장

• JWT: JSON Web Token, 클라이언트가 처음 인증을 받을 때(즉, 로그인 할 시) 두가지 토큰을 부여함

  1. Access Token
     • 보호된 정보들(유저의 이메일, 연락처, 사진 등)에 접근 권한 부여에 사용
     • 보안을 위해 비교적 짧은 유효기간을 지님
  2. Refresh Token
     • Access token의 유효기간이 만료되면, 이를 재발급 받기 위해 사용됨
     • refresh token은 재로그인의 번거로움을 걷어내기 위한 편의 사항으로 보면 됨
     • 보안에 더 초점을 두는 웹사이트들은 refresh token을 사용하지 않는 경우도 많음
     • 은행으로 예를 들면, 로그인 시간에 제한을 두고 그 시간이 지나면 다시 재로그인을 요청함

• JWT 구조: Header.Payload.Signature 3부분으로 이루어짐

  1. Header: 어떤 종류의 토큰인지, 어떤 알고리즘으로 sign할지가 적혀있음
     • JWT는 JSON 형태로 { "alg":"HS256", "typ":"JWT" } 이런 형태를 가짐
     • 위의 JSON 객체를 base64 방식으로 인코딩하면 JWT의 첫 블록이 됨
  2. Payload: 필요한 정보를 담는 부분
     • 정보 접근 권한이나 사용자 이름 등 필요한 데이터를 담아 sign시킴
     • 민감한 정보는 담지 않는 것이 좋다
     • { "sub":"someInfo", "name":"phil", "iat":"151623" }
     • header와 마찬가지로, 위 JSON 객체를 base64 방식으로 인코딩하면 두번째 블록이 됨
  3. Signature: 1,2번 블록을 완성하고, 원하는 비밀 키(암호화에 추가할 salt)를 사용하여 암호화
     • base64는 디코딩하기 쉽지만 비밀키가 없다면 해독에 많은 시간과 노력이 필요함
     • 예로, HMAC SHA256 알고리즘(암호화 방식 중 하나)을 사용한다면 signature는 아래와 같은 방식으로 생성됨
     • HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

• JWT 사용 예시

  • JWT는 권한 부여에 굉장히 유용함
  • 새로 다운받은 A라는 앱이 Gmail과 연동되어 이메일을 읽어와야 한다고 가정
    1. Gmail 인증서버에 로그인 정보(아이디, 비밀번호)를 제공
    2. 성공적으로 인증 시 JWT를 발급받음
    3. A 앱은 JWT를 사용, 해당 유저의 Gmail의 이메일을 읽거나 사용함

• 토큰기반 인증 절차

  1. 클라이언트가 서버에 ID/PW를 담아 로그인 요청을 보냄
  2. ID/PW를 확인, 클라이언트에 보낼 토큰을 생성
     • access/refresh token을 생성
     • 토큰에 담길 정보(payload)는 유저 식별 정보, 권한 부여 목록(사진, 연락처 등)
     • 두 종류의 토큰이 같은 정보를 담을 필요는 없음
  3. 토큰을 클라이언트에 전달
     • 저장 위치는 local storage, cookie, react의 state등 다양하다
  4. 클라이언트가 HTTP 헤더(authorization 헤더)에 토큰을 담아 보냄
     • bearer authentication을 이용한다
  5. 서버는 토큰을 해독, 인증 후 클라이언트의 요청을 처리한 후 응답을 보내준다
     

• 토큰기반 인증의 장점

  1. Statelessness & Scalability (무상태성 & 확장성)
     • 서버는 클라이언트에 대한 정보를 저장할 필요가 없음(토큰 해독 여부만 판단)
     • 클라이언트는 새로운 요청을 보낼 때 토큰을 헤더에 포함시키면 됨
     • 서버를 여러 개 가지고 있는 서비스일때 더욱 장점이 됨(같은 토큰으로 여러 서버에서 인증)
  2. 안전하다: signature를 받은 토큰을 사용, 암호화 키를 노출할 필요가 없음
  3. 어디서나 생성 가능
     • 토큰을 확인하는 서버가 토큰을 만들어야하는 법이 없음
     • 토큰 생성용 서버를 만들거나, 다른 회사에 토큰 관련 작업을 맡기는 등 다양한 활용 가능
  4. 권한 부여에 용이함: 토큰의 payload(내용물) 안에 접근 권한을 정할 수 있음(사진과 연락처 권한만 부여)

퇴근후개발공부 - 리프레쉬 토큰의 필요성