TIL 13주차 2일(1)_Session, Token

Sang heon lee·2021년 9월 7일
0

TIL 리스트

목록 보기
51/60

세션 기반 인증 (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) 서비스의 사진과 연락처 사용권한만 부여
profile
개초보

0개의 댓글