토큰기반 인증(JWT)
- 세션기반 인증은, 서버(or DB)에, 유저정보를 담는 방식이었다.
그니까 지금까지 세션으로 인증하는 방식은, 서버 혹은 db에 유저정보를 담아서 인등해주는 방식이었음
서버에서는 유저가 민감하거나 제한된 정보요청시, 괜찬은건지 확인위해, 갖고있는 세션값과 일치한지 살펴보기위해, 매번 db에 접근해서 비교해야 했음. - "이 부담을.. 클라이언트에게 넘겨줄순 없을까..??ㅠㅠ(클라이언트: ??)"에서 고안되었다고 함.
- 대표적인 토큰기반 인증 -> 'JWT(JSON Web Token)'
what is Token?
- '화폐로 사용하는 토큰을 생각해보라..!'
ex) - 오락실에서 사용하는 토큰'
ex) - 행사에 입장 시 사용하는 토큰
ex) - 놀이공원에 입장료를 내면, 주는 토큰.위의 공통점 : "난 돈 지불했고, 이 시설 이용 가능해! "란 메시지 담고있는거임.
토큰 인증 방식은, 인증정보를 저장하는 방식으로 고안되었음. 서버에게 이 토큰을 보여주면,
다양한 기능 이용이 가능할꺼임. 놀이공원이 이해감 ㅇㅇ
❓근데 이 토큰을... 과연 클라이언트에게 저장해도, 괜찮나❓
: 여기서 토큰은, '유저정보를 암호화한 상태로 담을 수 있고', 그래서 암호화했기 때문에,
클라이언트에 담을수 있는거임 ㅇㅇ
JWT(JSON Web Token)
: json포맷으로, 사용자에 대한 속성을 저장하는 웹 토큰. 대표적인 토큰기반 인증
JWT의 구조
ex) aaaaaa.bbbbbb.cccccc
header >payload >signature
(1) Header
- 어떤 종류의 토큰(지금은 JWT)인가?
- 어떤 알고리즘으로 암호화(sign)하는가? ex){'alg':'HS256', 'typ':'JWT'} => 얘를 basic64방식으로 인코딩하면 JWT의 첫번째 부분이 완성된다.(2)Payload
- 유저의 정보(사용자 아이디 등..) > 암호화될거지만,그러나 역시 민감한 정보는 담지 x
- 어떤 정보에 접근이 가능한지 등..권한을 부여 받았는가?
- 기타 필요한 정보..
ex) {'sub' :'someInformation',
'name':'phillip',
'iat' : 151623391
}=> 얘를 basic64방식으로 인코딩하면 JWT의 두번째 부분이 완성된다.
(3) Signature : basic64로 인코딩된, 이 header와 payload가 완성이 됐다면,
그 두 값에 salt값(=비밀 키)을 추가하여
암호화시킨 것 이다.
=> 이 basic64로 인코딩한 값은, 누구나 쉽게 디코딩을 할수있지만,
서버의 비밀키를 갖고있지 않다면
해독하는데 엄청 많은 시간이 들 것이다.
ex) HMACSHA256( //HMAC SHA256 알고리즘(암호화 방법중 하나)를 사용해 인코딩한 방식
base64UrlEncode(header) + "."+
base64UrlEncode(payload),
secret
)JWT의 종류
- ACCESS TOKEN
- REFRESH TOKEN
ACCESS TOKEN
: 보호된 정보들(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한부여에 사용.
클라이언트가 처음 인증을 받게 될 때(로그인시), access, refresh token 두가지를 한번에 다 받는다만,
=> 실제로 권한을 얻는데 사용하는 토큰은 'ACCESS TOKEN'.
❓그럼 access token만 있으면 되는 것 아닌가?
하지만 access token을 만약 악의적인 유저가 얻어냈다면?
이 악의적인 유저는 자신이 00유저인것 마냥 서버에 여러가지 요청을 보낼 수 있을것이다.
그렇기 때문에 access token에는 비교적 짧은 유효기간 을 주어 탈취 되더라도
오랫동안 사용할 수 없도록 하는것이 좋다.
Access token의 유효기간이 만료된다면
refresh token을 사용하여 새로운 access token을 발급 받는것이고,
그러므로 이때, 유저는 다시 로그인 할 필요가 없다.
❗refresh token도 탈취 당한다면?❗
유효기간이 긴 refresh token마저 악의적인 유저가 얻어낸다면 큰 문제가 될 것이다.
오랜 기간동안 access token이 만료되면 다시 발급 받으며 유저에게 피해를 입힐 수 있기 때문이다.
그렇기 때문에 유저의 편의보다 정보를 지키는 것이 더 중요한 웹사이트들은 refresh token을 사용하지 않는 곳이 많다.
다른 방법들을 적절히 사용해야 한다.
세션 vs 토큰
세션 : 접속상태를 서버가 가짐(stateful).
접속상태, 권한부여를 위해, 세션아이디로 쿠키로 전송한다.
- 접속 상태 저장 경로 : 서버
- 장점 : 신뢰할수있는 유저인지, 서버에서 추가로 확인가능.
- 단점 : 하나의 서버에서만 접속상태를 가지므로, 분산에 불리.
토큰 : 토큰 자체로도 무결성(integrity)을 증명할수있다.
- 접속 상태 저장 경로 : 클라이언트(쿠키,스토리지,인메모리..)
- 장점 : 어디서나 생성이 가능하니까, 확장성을 가지게된다.
- 단점 : 모든 요청에, 토큰을 실어보내야한다....
토큰기반 인증 절차
- 먼저 클라이언트가 서버에 아이디와 비번을 담아서 로그인요청을 보낸다. (POST /login) ✅
- 그러면 서버는, 이 아디/비번이 일치하는지 확인하고 암호화된 access토큰을 생성한다.생성되면 클라이언트에게 보냄
(JWT Token) ✅ - 클라이언트는 이 토큰을 받는다. 이때, 로컬스토리지 or 쿠키 or 리액트의 state 등..다양한공간에 저장함.
- 클라이언트가 http헤더에 토큰을 담아서(ex) Headers: {Authentication: 'Bearer JWT_TOKEN'})
서버에게 어떠한 정보들을 달라고 요청을 함. (GET /someInfo) - 그러면 서버는 이 JWT_TOKEN을 해독을 해서, 서버 본인이 발급한 토큰이 맞는지 확인한 후,
이제 클라이언트가 보낸 요청처리를 하고 응답을 보내준다.(request)
