간편인증 로그인 원리 완벽 이해하기 - PIN, 공개키, 개인키, 전자서명까지 한 번에 정리

간편인증은 비밀번호 로그인이 아니다

카카오 인증, PASS 인증, 공동인증서, 금융인증서 등 대부분의 간편인증 서비스는 일반적인 ID/PW 로그인 방식과 전혀 다른 원리로 동작합니다.

많은 사람들이 "PIN이 비밀번호다."라고 생각하지만 실제로는 그렇지 않습니다.

간편인증의 핵심은 서버가 사용자의 비밀번호나 개인키를 보관하지 않는다는 것입니다.

이번 글에서는 간편인증이 어떤 구조로 동작하는지, 서버에는 무엇이 저장되고 로그인은 어떻게 검증되는지 단계별로 쉽게 알아보겠습니다.

---

일반 로그인과 간편인증 로그인 차이

먼저 일반적인 로그인 방식부터 살펴보겠습니다.

일반 로그인

사용자
   │
ID / PW 입력
   │
   ▼
서버
   │
DB에 저장된 비밀번호와 비교
   │
로그인 성공

이 방식에서는 서버가 사용자의 비밀번호(또는 해시값)를 보관하고 있습니다.

사용자가 입력한 비밀번호와 DB에 저장된 값을 비교하여 로그인을 처리합니다.

즉, 서버는 사용자의 비밀번호와 관련된 정보를 반드시 가지고 있어야 합니다.

---

간편인증 로그인

반면 간편인증은 다음과 같이 동작합니다.

사용자
    │
PIN 입력
    │
전자서명 생성
    │
    ▼
인증서버
    │
전자서명 검증
    │
로그인 성공

여기서 가장 중요한 점은 다음과 같습니다.

• 서버는 PIN을 모릅니다.
• 서버는 개인키(Private Key)를 모릅니다.
• 서버는 공개키(Public Key)만 가지고 있습니다.

즉, 서버는 사용자의 비밀을 저장하지 않습니다.

---

회원가입 시 어떤 일이 발생할까?

회원가입(인증서 발급) 과정에서는 SDK가 공개키와 개인키를 생성합니다.

SDK

privateKey 생성
publicKey 생성

이 두 개는 항상 한 쌍(Key Pair)으로 생성됩니다.

예를 들어 홍길동이 회원가입한다고 가정해 보겠습니다.

홍길동

privateKey
ABCD1234...

publicKey
XYZ9999...

여기서 중요한 점은 저장 위치입니다.

항목저장 위치

Private Key	사용자 PC 또는 모바일 SDK
Public Key	인증 서버

---

서버에는 무엇이 저장될까?

예를 들어 DB가 다음과 같다고 가정해보겠습니다.

USER

IDNAME

1001

홍길동

TOKEN

tokenIdpublicKey

A12345

XYZ9999...

즉 서버에는

• tokenId
• publicKey

만 저장됩니다.

절대로 저장하지 않는 것은

• privateKey
• PIN

입니다.

---

개인키는 어디에 있을까?

개인키는 서버가 아니라 사용자의 기기에 저장됩니다.

PC

SDK
 ├── privateKey
 └── PIN

많은 사람들이 PIN을 비밀번호라고 생각하지만 실제 역할은 조금 다릅니다.

PIN은 개인키를 사용할 수 있도록 잠금을 해제하는 역할입니다.

PIN 입력
      │
      ▼
privateKey 사용 가능
      │
      ▼
전자서명 생성

PIN은 서버에 전달되지 않습니다.

---

실제 로그인 과정

STEP 1. 로그인 시작

사용자가 로그인 버튼을 누릅니다.

SDK는 자신이 보관 중인 인증서를 확인하여 tokenId를 가져옵니다.

예를 들어

tokenId

A12345

---

STEP 2. tokenId 전송

클라이언트는 서버로 tokenId를 전송합니다.

POST /login/start

tokenId=A12345

---

STEP 3. 서버에서 Challenge(Random) 생성

서버는 tokenId를 조회하여 공개키를 찾습니다.

tokenId

A12345

↓

publicKey 조회

하지만 여기서 바로 로그인시키면 보안상 문제가 발생합니다.

만약 tokenId만 알고 있어도 로그인된다면 공격자가 tokenId만 탈취해도 로그인이 가능하기 때문입니다.

그래서 서버는 사용자가 진짜 개인키를 가지고 있는지 확인해야 합니다.

이를 위해 일회용 난수(Random, Challenge)를 생성합니다.

예를 들어

random

1234567890

그리고 클라이언트에게 전달합니다.

"이 값을 개인키로 서명해서 보내주세요."

---

STEP 4. SDK에서 전자서명 생성

SDK는

• privateKey
• random

을 이용하여 전자서명을 생성합니다.

sign(privateKey, random)

↓

ASDFGHJKLQWERTY...

이 과정에서 PIN이 사용됩니다.

PIN 입력
      │
      ▼
privateKey 사용 허가
      │
      ▼
전자서명 생성

PIN은 오직 개인키를 사용할 수 있도록 허가하는 역할만 합니다.

---

STEP 5. 서버로 서명 전달

클라이언트는 다음 정보를 서버로 전달합니다.

tokenId

A12345

random

1234567890

signData

ASDFGHJKLQWERTY...

---

STEP 6. 서버 검증

서버는 tokenId를 이용하여 공개키를 조회합니다.

그리고 다음과 같이 검증합니다.

verify(
    publicKey,
    random,
    signData
)

검증 결과는 두 가지입니다.

검증 성공

OK

의미는 다음과 같습니다.

해당 개인키를 가진 사용자가 서명을 생성했다.

즉 사용자가 실제 개인키를 가지고 있다는 것이 증명됩니다.

이후 서버는 JWT 또는 세션을 발급하여 로그인을 완료합니다.

검증 실패

NG

서명이 올바르지 않거나 데이터가 변경되었거나 개인키가 일치하지 않는 경우입니다.

로그인은 실패합니다.

---

공개키만으로 검증이 가능한 이유

공개키 암호화는 다음과 같은 특징을 가지고 있습니다.

privateKey
      │
      ▼
전자서명 생성
      │
      ▼
publicKey
      │
      ▼
검증 가능

반대로는 불가능합니다.

publicKey

↓

전자서명 생성

불가능

즉 공개키는 검증만 가능하며 서명을 만들 수는 없습니다.

이것이 공개키 암호화 방식의 핵심입니다.

---

Replay Attack(재전송 공격)은 어떻게 막을까?

로그인할 때마다 서버는 새로운 난수를 생성합니다.

예를 들어

오늘

123456

내일

99887766

처럼 매번 다른 값을 사용합니다.

따라서 공격자가 예전에 사용했던 서명을 다시 보내더라도 검증은 실패합니다.

사용한 random은 검증 후 즉시 삭제되기 때문입니다.

이것이 Replay Attack(재전송 공격)을 방지하는 방식입니다.

---

PIN은 비밀번호가 아니라 금고의 열쇠

PIN은 로그인 비밀번호가 아닙니다.

비유하면 다음과 같습니다.

PIN
   │
   ▼
금고(Open)
   │
privateKey 사용
   │
전자서명 생성

즉,

• PIN은 서버로 전송되지 않습니다.
• PIN은 개인키 사용을 허가합니다.
• 실제 로그인은 개인키로 생성한 전자서명을 검증하여 이루어집니다.

---

전체 구조 한눈에 보기

회원가입

             회원가입

             SDK
               │
      ┌────────────────────┐
      │ privateKey 생성     │
      │ publicKey 생성      │
      └────────────────────┘
               │
      privateKey 로컬 저장
               │
               └──────────────► 서버
                                │
                     publicKey 저장
                     tokenId 저장

로그인

사용자
    │
PIN 입력
    │
privateKey 사용
    │
random(Challenge) 서명
    │
──────────────► 인증서버
                │
      tokenId로 publicKey 조회
                │
      전자서명 검증(verify)
                │
          검증 성공
                │
      JWT 또는 세션 발급
                │
         로그인 완료

---

인증서버의 역할

1. 회원가입(인증서 발급)

• 공개키(Public Key) 저장
• tokenId 저장
• 개인키(Private Key)는 저장하지 않음

2. 로그인 시작

• tokenId 유효성 확인
• 일회용 난수(Random) 생성
• 난수를 임시 저장 후 클라이언트에 전달

3. 로그인 검증

클라이언트가 전달한

• tokenId
• random
• signData

를 이용하여

1. tokenId로 공개키 조회
2. 공개키로 전자서명 검증
3. 검증 성공 시 JWT 또는 세션 발급
4. 사용한 random 즉시 삭제

---

정리

간편인증의 핵심은 "서버는 비밀을 저장하지 않는다."는 것입니다.

사용자는 개인키를 직접 보관하고, 서버는 공개키만 저장합니다.

로그인할 때마다 서버는 새로운 Challenge(Random)를 생성하고, 사용자는 개인키로 전자서명을 생성합니다. 서버는 공개키를 이용해 이 서명을 검증함으로써 사용자가 실제 개인키를 소유하고 있는지 확인합니다.

또한 PIN은 로그인 비밀번호가 아니라 개인키를 사용할 수 있도록 허가하는 잠금 해제 수단이며, 서버에는 절대 전달되지 않습니다.

이 구조를 이해하면 001 → SDK의 sign() → 002 흐름이 왜 필요한지 자연스럽게 이해할 수 있으며, 공개키 기반 인증(PKI)이 높은 보안성을 제공하는 이유도 함께 이해할 수 있습니다.