인증(Authentication) / 인가(Authorization)

쿠키 세션 JWT 관한 글

인증 & 인가

1. 인증(Authentication) : 서비스를 이용하려는 유저가 등록된 회원인지 확인하는 절차
   -> 로그인 기능을 생각하면 됨

2. 인가(Authorization) : 인증을 받은 유저가 특정 리소스에 접근할 수 있는 권한 이 있는지 확인하는 절차
   -> 로그인 이후의 기능들을 사용할 때를 생각할 것

서버와 클라이언트의 관계

왼쪽 그림 HTTP 프로토콜의 특징

• 서버와 클라이언트는 연결이 되어 있지 않음
• 서버 입장에서는 항상 새로운 요청임

쿠키 세션 토큰

• http의 비연결성에도 불구하고 어떻게 서버 <-> 클라이언트는 지속해서 요청이 가능할까?
  Ex) 로그인 상태가 유지되고, 로그인 된 유저만 누릴 수 있는 서비스를 서버에서 제공

쿠키

• 쿠키란 브라우저에 저장되는 작은 데이터 조각이며 key-value형태로 저장 됨.
• http의 무상태성(stateless)과 비연결성(connectionless) 특성에도 불구하고, 쿠키를 사용해 마치 서버와 클라이언트가 연결된 것처럼 구현할 수 있다.
• 서버에 http요청을 할 때 마다 브라우저에 저장된 쿠키는 자동으로 서버에 보내진다.
  (단, 동일한 Origin 또는 CORS를 허용하는 Origin에만 쿠키를 보낸다. Ex- 유튜브 서버에서 받은 쿠키는 유튜브 이용 시에만 사용가능)

Origin

서버 주소가 http://localhost:5000이라면 요청을 보낼 수 있는 클라이언트 서버도 http://localhost:5000로 동일 해야함

주의

쿠키는 클라이언트에서 직접 추가/삭제/수정이 가능

세션

• 세션이란 클라이언트와 서버간의 연결이 활성화 된 상태을 의미한다. 또는 인증(Authorization) 유지되고 있는 상태
• 로그인 성공 -> 서버에서 세션 생성 및 저장(key-value형식) -> 생성된 sessionId를 쿠키에 담아 브라우저에 전달

쿠키-세션 인증 방식

1. 로그인/회원가입 시 세션 인증
   

• 로그인/회원가입 성공 시 서버에서 쿠키에 sessionId를 담아서 보냄

2. 인가(Authorization) 시 세션 인증
   

• API 요청을 받으면 클라이언트 쿠키에 들어 있는 sessionId를 세션 저장소에 조회하여 있으면 DB에 데이터를 조회하여 응답

토큰

• 토큰이란 클라이언트에서 보관하는 암호화 또는 인코딩된 인증 정보
• 서버의 상태를 유지하지 않고 클라이언트의 인증 상태를 확인할 수 있음
• 세션처럼 서버에서 사용자의 인증 정보를 보관할 필요가 없기 때문에 서버 부담을 줄여주는 인증 수단

암호화 vs 인코딩

	암호화	인코딩
목적	데이터 기밀성 및 보안 강화	데이터 전송 및 저장 효율성 개선
방식	비밀키 또는 공개키를 사용	공개된 규칙을 사용
예시	ASCII, Base64 등	SHA256, HTTPS, RSA 등

암호화는 데이터를 인가된 사람만 읽을 수 있는 반면 인코딩은 아무나 읽을 수 있다.

JWT

JWT : 토큰 기반 인증 방식

1. Header : 토큰 종류 + 알고리즘

2. Payload : 중요 데이터가 담겨 있음. 사용자의 id, 토큰 만료시간 등

3. Signature : 토큰의 위변조 확인. 서버만 알 수 있는 비밀키를 사용해 토큰의 무결성 보장

JWT 특징

1. 인코딩된 데이터를 누구나 복호화 해 payload를 볼 수 있음
   토큰의 용도는 인증정보(payload)에 대한 보호가 아닌 위조 방지
2. 정보(payload)를 토큰화할 때 signature에 secret key가 필요하고, secret key는 복호화가 아니라 토큰이 유효한 지를 검증하는 데 사용

JWT 인증 방식

1. 로그인/회원가입 시 토큰 인증
   

2. 인가(Authorization) 시 토큰 인증
   

중요

☝ Refresh Token 으로 보안을 강화하는 것은 중요해요!

다만, 이를 위해서는 각종 토큰을 발급해주는 영역의 백엔드 개발자와의 협업이 필요해요. 우리 과정에서는 이 부분까지 실습하지는 않습니다 🙂 Firebase, Supabase에서는 자체적인 시스템에서 access token, refresh token을 처리하고 있으니 하기 개념은 ‘교양’ 정도로 알고 계시면 좋을 것 같아요.

리소스 접근 인가를 받기 위해 사용되는 토큰을 Access Token 이라고 부릅니다.

Access Token의 만료기간을 길게 잡고 인증상태를 오래 가져갈 경우 서버 부담은 줄어드나 보안성(탈취 당할 경우)에 허점이 있습니다.

인증 보안이 중요한 서비스의 경우 인증 시 2개의 토큰 (Access Token, Refresh Token)을 발급합니다. Access Token의 기간은 30분 정도로 짧게 가져 가고, Refresh Token은 1~2주 정도로 길게 잡는 경우가 많습니다.

이 경우 서버에서는 Access Token이 만료되었을 때 Refresh Token 이 유효한 상태면 새로운 Access Token을 클라이언트에 발급해주고 인증상태를 유지할 수 있도록 하고, Refresh Token 만료 시 다시 로그인하라는 메시지를 응답합니다.