세션 기반 인증 (Session-based Authentication)
1. Session
-
로그인을 성공하면 서버는 세션 아이디(session_id)를 쿠키에 담아 클라이언트에 보내주게 됩니다.
-
이후 클라이언트는 요청시마다 쿠키에 세션 아이디를 담아서 보내주게 되고, 서버는 해당 클라이언트가 로그인중 임을 알게 되고 해당 요청이 인증되었음을 알게됩니다.
-
세션 기반 인증 방식에서 주체(아이디 , 비밀번호 등 데이터)는 서버입니다.
-
클라이언트는 단지 세션 아이디 하나 만을 가지고 있을 뿐입니다.
-
express에는 세션을 관리해주는 모듈
express-session이 존재합니다.
https://github.com/expressjs/session#reqsession
토큰 기반 인증 (Token-based Authentication)
2. Token
- 세션 기반 인증 방식에는 단점이 존재합니다.
- 민감한 정보를 서버가 가지고 있다.
- 서버에 부담이 심하다.
- 이러한 단점을 보완하고자 토큰 기반 인증 방식이 존재하고 대표적으로 JWT(JSON Web Token)이 존재합니다.
2.1 JWT(JSON Web Token)
2.1.1 JWT 의 종류
-
Access Token : 보호된 정보들(이메일, 연락처 등)에 접근할수 있는 권한 부여
-
Refresh Token : 비교적 유효기간이 짧은 Access Token을 갱신하는데 사용하는 토큰
2.1.2 JWT 의 구조 
-
Header : 어떤 정류의 토큰인지, 어떤 알고리즘으로 암호화할지가 적혀있습니다.
-
Payload : 접근 가능한 권한, 유저 이름 등 데이터(정보)가 담겨 있습니다.
-
Signature : 암호화에 추가할 salt(비밀키)
2.2 토큰 기반 인증 절차
- 클라이언트가 로그인 요청을 한다.
- 서버는 로그인 정보를 확인하고 토큰을 생성한다.
- 서버는 클라이언트에게 토큰을 보내고, 클라이언트는 토큰을 저장한다.
- 이후 클라이언트는 요청시 마다 토큰을 같이 보낸다.
Header : {authorization: `Bearer ${accessToken}`}
2.3 토큰 기반 인증 의 장점
2.3.1 Statelessness & Scalability (무상태성, 확장성)
- 서버는 클라이언트에 대한 정보를 저장할 필요가 없습니다.
(토큰이 복호화 되는지만 판단합니다.)
- 클라이언트는 새로운 요청을 보낼때마다 토큰을 헤더에 포함시키면 됩니다.
- 서버를 여러개 가지고 있는 서비스라면 더더욱 빛을 발휘합니다 (같은 토큰으로 여러 서버에서 인증 가능)
2.3.2 안전하다
- 암호화 한 토큰을 사용하고, 암호화 키를 노출 할 필요가 없기 때문에 안전합니다.
2.3.3 어디서나 생성 가능하다
- 토큰을 확인하는 서버가 토큰을 만들어야 하는 법이 없습니다
- 토큰 생성용 서버를 만들거나, 다른 회사에서 토큰관련 작업을 맡기는 것 등 다양한 활용이 가능합니다
2.3.4 권한 부여에 용이하다
- 토큰의 payload(내용물) 안에 어떤 정보에 접근 가능한지 정할 수 있습니다
ex) 서비스의 사진과 연락처 사용권한만 부여
