[Authentication/Security] Token-based Authentication

Token-based Authentication

Session vs Token = 인증정보가 어디에 저장되는가?

• Session -> client, server
• Token -> server

Client-only 인증방식 - 서버의 부하를 줄임.

Token 은 유저 정보를 암호화한 상태로 담을 수 있고, 암호화 했기 때문에 클라이언트에 보관할 수 있다.

JWT

JSON Web Token

Server 의 salt 값으로 signature 를 만듦.

종류

Access token, Refresh token

• 인증을 거쳐야만 접근할 수 있는 정보 (개인정보 등)에 접근할 수 있는 권한부여에 사용
• 클라이언트가 처음 인증을 받을 때 (로그인할때 등) access, refresh 두개를 받는데, 실제 권한을 얻는데 사용하는 token 은 access. access 가 만료될 경우 다시 발급받는 용도인 refresh token
• Access token 이 범죄자에게 탈취될 가능성을 고려하여 짧은 유효기간을 부여한다. Access 가 만료되면 refresh token 을 이용하여 새로운 access token 을 발급받는다. 이런 구조로 유저는 acess 가 만료되어도 다시 로그인할 필요가 없어진다.
• Refresh 도 탈취될 가능성이 있기 때문에 유저의 편의보다 정보를 지키는 것이 더 중요한 웹사이트들은 refresh token 을 사용하지 않는 곳도 많다. 각 보안 방법의 장단점을 참고하여 사용해야 한다.

구조

1. Header

{
  "typ": "JWT" // 토큰의 종류
  "alg": "HS256", // 알고리즘
  "
}

2. Payload
   내가 담고싶은 정보를 JSON 형태로 담는다. 암호화 되겠지만, 민감한 정보는 되도록 담지 않는다.

3. Signature
   salt 를 추가하여 암호화한다.

HMAC SHA256 알고리즘을 사용한 예제

HMACSHA256(
  base64UrlEncode(header)
  + '.' 
  + base64UrlEncode(payload), 
  secret
)

흐름

1) 클라이언트가 서버에 로그인 요청

2) id/pw 일치 시 access/refresh 토큰 생성

• 토큰에는 유저 식별 정보, 권한이 부여된 카테고리 등이 될 수 있음.
• 두 토큰에 같은 정보를 담을 필요는 없음.

3) 클라는 받은 토큰을 저장.

• local storage, cookie, react state 등 다양

4) 클라에서 요청 시 http header 에 토큰을 담아 보냄.

• bearer authentication 을 이용

5) 서버에서 토큰을 해독하여 자신이 발급해준 토큰인지 확인 후 요청 처리

Token authentication 장점

1) Statelessness, Scalability

무상태성, 확장성

• 서버는 클라에 대한 정보 저장 x. secret key 가져와서 토큰해독만 하면 됨.
• 서버가 많아도 상관없음.

2) Secure

• token 은 암호화되어있고, secret key 는 서버에 저장되어있기 때문에 안전

3) Any place

• 일반 서버, 토큰 생성용 서버, 다른 회사에 토큰 작업 맡기기 등 다양한 방식 사용가능

4) Easy to grant authorization

• 토큰의 payload 에 접근 권한 정보를 넣을 수 있다.

---

https://www.digitalocean.com/community/tutorials/nodejs-jwt-expressjs