인증/인가 (Authentication & Authorization)

웹 서비스에서는 사용자를 구분하고, 각 사용자에게 허용된 기능만 사용할 수 있도록 제한해야 합니다.

이때 필요한 개념이 인증(Authentication)과 인가(Authorization)입니다.

---

1. 인증(Authentication)과 인가(Authorization)의 차이

인증은 누구인지 확인하는 과정입니다. 예를 들어 로그인할 때 ID/비밀번호를 검증하거나 “이 사람이 실제로 이 계정 주인인가?”를 확인하는 것을 말합니다.

 

인가는 인증된 사용자가 무엇까지 할 수 있는지 권한을 부여하는 과정입니다. 예를 들어 일반 사용자는 글을 읽기만 가능하고, 관리자만 사용자 정보를 수정할 수 있게 하는 것이 인가입니다.

⇒ 로그인은 인증, 권한 체크는 인가

---

2. Session 기반 인증 (전통적인 방식)

세션 인증은 서버가 사용자의 로그인 상태를 직접 관리하는 방식입니다.

 

2-1. 동작 흐름

1. 사용자가 로그인 정보를 서버에 전송합니다.
2. 서버는 비밀번호를 확인한 뒤, 사용자 정보를 서버 메모리 (또는 Redis)에 저장합니다.
3. ⇒ 이것이 세션(Session)입니다.
4. 서버는 사용자에게 세션 ID를 담은 쿠키를 발급합니다.
5. 사용자가 다음 요청을 보내면, 브라우저는 자동으로 세션 쿠키를 포함해서 보냅니다.
6. 서버는 쿠키 안의 세션 ID를 확인하여 이 사용자가 누구인지를 판단합니다.

2-2. 장점

• 서버에서 세션을 직접 관리하므로 안전합니다.
• 구조가 단순하여 구현이 쉽습니다.

2-3. 단점

• 서버가 모든 사용자의 세션을 저장해야 합니다.
• 서버가 늘어나면 세션 동기화가 필요합니다 (→ 보통 Redis를 사용해 해결)
• 모바일/다른 클라이언트에서 쓰기 번거롭습니다.
  • ⇒ 세션은 쿠키 기반이고, 쿠키는 브라우저 전용 개념이기 때문

---

3. Token 기반 인증 (Session을 저장하지 않는 방식)

세션기반 인증의 단점을 해결하기 위해 서버가 사용자의 로그인 상태를 직접 저장하지 않고, 사용자에게 토큰(Token)을 발급하여 인증에 사용하도록 하는 방식입니다.

 

3-1. 동작 흐름

1. 사용자가 로그인 정보를 서버에 전송합니다.
2. 서버는 비밀번호를 확인한 뒤, 사용자 정보를 암호화하여 토큰을 생성합니다.
3. 이 토큰을 사용자에게 전달합니다.
4. 사용자는 이후 요청마다 토큰을 Authorization 헤더에 담아서 서버로 보냅니다.
5. 서버는 토큰을 해석하고, 사용자 정보를 확인하여 인증을 진행합니다.

3-2. 장점

• 서버가 세션을 저장하지 않아도 돼 확장성이 뛰어납니다.
• 모바일/웹/외부 서비스에서도 쉽게 사용됩니다.
• 분산 서버 환경에 적합합니다.

3-3. 단점

• 토큰이 노출되면 위험합니다.
• 토큰 자체를 서버가 무효화시키기 어렵습니다. (→ Refresh Token으로 해결)

---

4. JWT(Json Web Token) 구조

JWT는 토큰 기반 인증에서 가장 많이 사용하는 형식입니다.

JWT는 . 으로 구분된 3개의 문자열로 구성됩니다.

xxxxx.yyyyy.zzzzz

각 파트의 의미는 다음과 같습니다.

 

4-1. Header

• 어떤 알고리즘으로 서명했는지 정보가 담겨 있습니다.

{
  "alg": "HS256",
  "typ": "JWT"
}

4-2. Payload

• 사용자 정보(Claim)가 들어 있습니다.
• ex) userID, 권한(role), 만료시간(exp)

{
  "sub": "user123",
  "role": "USER",
  "exp": 1690000000
}

4-3. Signature

• Header + Payload를 비밀키로 서명한 값입니다.
• 서버는 이 부분을 이용해 위조되지 않았는지 확인합니다.

---

5. Refresh Token이 필요한 이유

Acccess Token(JWT)은 보통 짧은 만료 시간을 가집니다.

하지만 이 방식에는 Access Token이 만료될 때마다 로그인을 다시 해야 하는 불편함이 발생합니다.

그래서 등장한 것이 Refresh Token입니다.

왜 만료시간을 짧게 둘까요?
⇒ 토큰이 유출되었을 때 피해를 최소화하기 위해서입니다.

 

5-1. Refresh Token이란?

• Access Token이 만료되었을 때 새로운 Access Token을 재발급받기 위한 인증 수단입니다.
• Access Token보다 더 긴 수명을 가진 Refresh Token을 활용해 자동 로그인처럼 유지하는 구조입니다.

5-2. Refresh Token 특징

• 더 긴 수명을 가집니다. (보통 며칠~몇 주)
• 서버가 Refresh Token을 저장하여 관리합니다.
• Access Token을 재발급하는 데 사용됩니다.

5-3. 흐름

1. Access Token 만료 → 클라이언트가 Refresh Token을 사용해 재발급 요청
2. 서버는 Refresh Token을 확인하고 Access Token을 새로 발급합니다.
3. Refresh Token도 주기적으로 갱신합니다.

---

6. OAuth 2.0 (소셜 로그인 등 외부 인증 방식)

OAuth 2.0은 사용자가 비밀번호를 직접 제공하지 않고, 다른 서비스(Google, Kakao, Apple 등)의 인증을 이용하는 방식입니다.

 

6-1. 왜 OAuth가 필요할까?

• 사용자 비밀번호를 제 3자 서비스에게 주지 않도록 만들기 위해서입니다.
• 인증을 직접 구현하지 않아도 외부 제공자의 신뢰된 인증을 이용할 수 있습니다.

6-2. OAuth 2.0 Authorization Code Flow (가장 많이 사용되는 방식)

구글 로그인을 예시로 들어보겠습니다.

1. 사용자가 우리 서비스에서 “구글 로그인” 버튼 클릭 → 우리 서비스는 구글 인증 서버로 리다이렉트 합니다.
2. 사용자는 구글에서 로그인 승인 → 구글이 “Authorization Code”를 우리 서버에게 전달합니다.
3. 우리 서버는 이 코드를 구글에게 보내고 Access Token을 요청 → 구글이 Access Token을 반환합니다.
4. 우리 서버는 Access Token을 이용해 → 구글 사용자 정보 API”에 접근하여 사용자 정보를 가져옵니다.
5. 우리 서비스는 해당 정보를 기반으로 회원가입 또는 로그인 처리합니다.