쿠키, 세션, JWT

📒인증, 인가

인증 (Authentication)

인증은 신원을 확인하는 프로세스입니다.
비밀번호, 하드웨어 토큰, 기타 여러 방법을 사용해야 합니다.

인가 (Authorization)

인가는 인증 이후의 프로세스입니다. 인증된 사용자가 어떠한 자원에 접근할 수 있는지를 확인하는 절차가 바로 인가이다.

비교

• 사이트에 가입된 사용자라는 것을 증명하는 것은 인증
• 인증 후에 페이지 접근 권한 여부를 확인하는 것은 인가

📒 로그인이란?

사용자가 시스템에 접근하거나 동작을 수행하는 것을 제어하고 기록하기 위한 컴퓨터 보안 절차

로그인이 필요한 이유와 구현을 위해 해야하는 것은?

1. 사용자 식별

해당 페이지에 접근하는 사용자가 누구인지 구분하기 위해

2. 접근 및 동작 제어

2-1. 권한이 없는 자원에 접근하지 않는 구조 만들기

• 관리자 전용 페이지와 데이터를 일반 유저가 접근하지 못하도록 github repo의 setting 버튼이 관리자를 제외하고는 보여지지 않도록 설정

2-2. 권한이 없는 자원의 존재를 모르도록 하기

• 관리자 페이지의 주소를 일반 유저가 직접 입력했을 때 오류 페이지를 보여줌으로써 권한이 없는 페이지&데이터를 숨기기

3. 인증 정보 관리하기

로그인이 계속 유지될 수 있도록 token을 쿠키, 로컬스토리지, 섹션스토리지에 저장 인증 정보를 저장해두지 않는다면 장바구니에 추가할 때도 로그인을 해야하고, 장바구니로 이동할 때도 로그인을 해야함

쿠키? 세션? JWT?

서버는 무상태성(stateless)기 때문에 상태 저장을 하지 않기 때문에, 매번 사용자에게 아이디와 비밀번호를 입력받을 수 없기 때문에 로그인을 유지(인증/인가)하기 위해 사용하는 방법들

1. 쿠키

HTTP 쿠키란 서버에서 사용자 브라우저로 전송하는 작은 데이터를 뜻한다.

브라우저는 서버에서 받은 데이터(Cookie)를 저장해 놓았다가 동일한 서버로 재요청 시 제공받았던 데이터를 함께 전송한다.

■ 쿠키를 사용한 로그인 기능

사용자가 로그인할 때
서버는 ID와 PW를 Cookie에 담아 응답하고,
이후 요청부터는 브라우저가 ID/PW를 Cookie에 담아 함께 보내기 때문에,
인증/인가를 위해 매번 아이디와 비밀번호를 입력하지 않아도 되게 된다.

■ 장점

• 기존 로그인을 위한 정보를 사용하기 때문에 인증/인가를 위한 추가적인 데이터 저장이 필요 없다.
• 서버에 정보를 저장하지 않기때문에 서버 저장 공간이 필요 없고, Stateless하다고 할 수 있다.

■ 단점

• 사용자의 주요 정보를 매번 요청에 담아야 하기에 보안이 취약하다.

2. 세션

쿠키의 취약한 보안을 해결하기 위해 사용하는 것이 세션
Session은 고객의 주요 정보가 아닌, 단지 고객을 식별할 수 있는 값 생성해 Cookie로 주고받는다.

사용자의 로그인 이후 로그아웃 혹은 로그인 만료까지의 기간

■ 세션를 사용한 로그인 기능

A 사용자가 ID/PW를 통해 로그인을 했다면
A사용자를 식별할 수 있는 값를 생성해 Cookie로 브라우저에 심고 매번 요청 때마다 생성한 값을 통해 인증/인가를 자동으로 진행한다.
이 때 생성되는 사용자 식별 값을 Session ID라 한다.

■ 장점

• 쿠키보다 보안이 비교적 좋다.

■ 단점

• 사용자를 식별할 수 있는 값을 생성하고 서버에 저장해두어야 한다.
• 서버 저장 공간이 필요하다.
• Stateless하다고 표현할 수 없다. (정보를 저장하기 때문에)

Token?

사용자를 인증할 수 있는 정보가 숨겨진 암호화된 Access Token을 발행하고, 인증이 필요할 때마다 서버에 Token과 함께 요청을 보낸다. 서버는 저장된 데이터가 아닌 Token 해독을 통해 Token 속에서 사용자를 식별할 수 있는 정보들을 알아내고 이를 바탕으로 인증/인가가 자동으로 진행한다.

3. JWT (Json Web Token)

JSON 형태의 데이터를 안정하게 전송하기 위한 토큰

jwt 공식 문서

■ JWT 구조

• Header: 토큰을 암호화하는데 사용한 알고리즘, 토큰 형태
• PAYLOAD: 사용자 정보
  • sub: 토큰 제목
  • iat: 언제 발급되었는지
• SIGNATURE: 암호화를 위한 데이터,
  • MY_SECRET_KEY : 서버만 알고 있고, 서버와 비교하여 유효성 검사할 데이터

■ 토큰 사용한 로그인 기능

서비스에 로그인 요청을 하면 서비스는 클라이언트에게 토큰을 발급하고, 전달한다.
클라이언트는 발급받은 토큰을 보관하고 있다가 토큰을 사용해 인증/인가를 요청한다.

■ 토큰 사용한 로그인 기능 - 실제 서비스

유저 진입 후 토큰을 가지고 있는 여부에 따라 다음 단계 결정
1-1. 토큰이 있는 경우 서버에 token의 유효성을 확인

• 토큰이 유효하다면 로그인 성공!
• 토큰이 유효하지 않다면 로그인 진행

1-2. 토큰이 없다면 로그인 진행

• 사용자의 id와 비밀번호를 받아 서버에 인증 정보를 확인하고, 서버에서 새로운 token을 발급받아서 로그인 성공!

---

참고 사이트

• 프리온보딩 로그인 기능
• 지마켓 기술 블로그 - 인증/인가는 어디에 어떻게 구현해야 할까?