자격증명 서비스 제공자

자격증명 서비스 제공자는 가입하는 사람이 누구인지 확인한 뒤 로그인 수단을 내줍니다. 내준 수단이 누구의 것인지 기록해 둡니다. 수단을 잃어버리거나 도둑맞으면 그 기록을 끊습니다. 로그인을 검사하는 쪽은 이 기록에 기대어 사람을 알아봅니다.

쉽고 빠른 이해

자격증명 서비스 제공자는 가입하는 사람이 누구인지 확인한 뒤 로그인 수단을 쥐여 줍니다. 회사 전산팀이 신입 직원의 신분증을 보고 사내 계정과 보안 키를 내주는 일이 그 예입니다.

처음에 누구인지 확인해 두지 않으면 로그인이 뜻을 잃습니다. 비밀번호가 맞아도 그 계정의 주인이 실제로 누구인지는 알 수 없습니다.

어떻게 도나:

1. 가입하려는 사람의 신원을 확인합니다
2. 비밀번호나 보안 키 같은 로그인 수단을 그 사람 계정에 묶어 기록합니다
3. 수단을 잃어버리면 기록을 끊습니다. 본인인지 다시 확인한 뒤 새 수단을 묶어 줍니다
4. 로그인을 검사하는 쪽은 이 기록을 보고 판단합니다

대가는 모든 로그인이 이 한 곳의 확인을 믿는다는 것입니다. 가입할 때 확인이 허술하거나 계정 복구가 느슨하면, 로그인 검사가 아무리 엄격해도 엉뚱한 사람이 통과합니다.

상세

운전면허 시험장은 응시자의 신분증을 보고 본인인지 확인합니다. 본인이 맞으면 그 사람 이름으로 면허증을 만들어 줍니다.

면허증을 잃어버리면 다시 만들어 줍니다. 면허가 취소되면 명부에 적어 둡니다. 도로에서 면허증을 검사하는 경찰은 이 명부를 믿습니다.

자격증명 서비스 제공자는 로그인에서 이 시험장의 일을 맡는 쪽입니다. 가입하려는 사람의 신원을 확인합니다. 확인이 끝나면 로그인 수단을 그 사람 계정에 묶어 줍니다. 회사 전산팀이 신입 직원의 신분증을 확인한 뒤 사내 계정과 보안 키를 내주는 일이 그 예입니다.

영어로는 CSP(Credential Service Provider)라고 줄여 씁니다. 같은 줄임말을 웹 보안의 콘텐츠 보안 정책도 씁니다. 그쪽은 브라우저가 어떤 스크립트를 실행할지 정하는 설정이라 이 편과는 무관합니다. 이 편에서는 줄임말 대신 우리말 이름을 씁니다. 문맥이 분명하면 줄여서 제공자라고 씁니다.

이 이름은 NIST(National Institute of Standards and Technology, 미국 국립표준기술연구소)의 디지털 신원 지침에서 왔습니다. 로그인 한 번을 여러 역할로 쪼개 보면 누가 무엇을 책임지는지가 드러납니다. 제공자는 그중 로그인보다 먼저 일하는 역할입니다.

이 역할이 따로 필요한 까닭은 로그인 검사가 답하는 물음이 좁아서입니다. 로그인 검사는 「이 비밀번호가 이 계정의 것과 맞나」만 답합니다. 「이 계정의 주인이 실제로 누구인가」는 답하지 못합니다. 그 답은 계정을 만들 때 한 번 확인해 적어 둔 기록에서만 나옵니다.

가입하는 사람의 세 이름

한 사람이 이 과정에서 단계마다 다른 이름으로 불립니다. 뒤에서 이 이름들을 계속 쓰므로 먼저 갈라 둡니다.

세 이름은 모두 같은 사람을 가리킵니다. 청구자는 영어 claimant 를 옮긴 말입니다. 주장이 맞는지 아직 모르는 상태라는 점이 가입자와 다릅니다.

인증수단과 자격증명

로그인할 때 사람이 내미는 것이 인증수단입니다. 비밀번호, 하드웨어 보안 키, 일회용 코드를 띄우는 휴대폰 앱이 모두 인증수단입니다. 인증수단은 가입자가 들고 다닙니다.

신원 관리에서 자격증명은 좁은 뜻으로 쓰입니다. 「이 인증수단은 이 가입자의 것이다」라고 묶어 둔 기록을 가리킵니다. 이 기록은 가입자가 아니라 제공자가 보관합니다.

일상 개발 대화에서는 비밀번호나 키 자체를 자격증명이라고 부릅니다. 이 편에서는 둘을 가릅니다. 가입자가 들고 다니는 것은 인증수단입니다. 제공자가 쥔 묶음 기록은 자격증명입니다.

제공자가 맡는 세 가지 일

제공자의 일은 셋으로 나뉩니다. 앞의 둘은 가입할 때 한 번 합니다. 마지막 하나는 자격증명이 살아 있는 동안 계속합니다.

아래 세 소절이 표의 세 줄을 하나씩 풉니다.

신원 증명

신원 증명은 신청자가 누구인지 확인하는 일입니다. 주장하는 사람이 실제로 있는지, 지금 신청하는 사람이 그 본인인지를 봅니다. 확인 없이 받은 이름은 신청자가 스스로 적은 값일 뿐입니다. 남의 이름으로 계정을 만들어도 막을 방법이 없습니다.

확인은 세 단계로 이루어집니다. 신청자가 댄 정보와 증거를 모읍니다. 그 증거가 진짜이고 아직 유효한지 확인합니다. 증거 속 사람이 지금 신청하는 사람과 같은지 대조합니다.

신분증으로 따라가면 이렇습니다. 신청자가 신분증 사진을 올립니다. 제공자는 신분증이 위조되지 않았고 기한이 남았는지 봅니다. 그다음 신분증 사진과 신청자의 얼굴을 맞춰 봅니다.

확인을 얼마나 꼼꼼히 하느냐는 서비스가 잃을 것에 따라 다릅니다. 아래 표는 흔한 세 경우를 보입니다.

게시판은 이름을 전혀 확인하지 않습니다. 은행은 세 단계를 다 거칩니다. 이 확인 강도를 등급으로 매긴 것이 신원 보증 수준입니다.

인증수단 등록

신원 증명을 통과한 가입자에게 인증수단을 묶어 줍니다. 제공자가 새 수단을 만들어 건네기도 합니다. 가입자가 이미 가진 보안 키나 휴대폰을 등록받기도 합니다.

묶을 때 제공자는 수단 자체가 아니라 나중에 확인할 때 쓸 값을 적어 둡니다. 비밀번호라면 원문 대신 해시 함수를 거친 값을 적습니다. 해시 함수는 결과에서 원문을 되짚기 어렵게 만든 함수입니다. 저장소가 털려도 비밀번호 원문은 바로 드러나지 않습니다.

보안 키라면 그 키의 공개 키를 적습니다. 공개 키는 짝을 이루는 두 키 가운데 남에게 알려도 되는 쪽입니다. 짝이 되는 개인 키는 보안 키 안에서 나오지 않습니다.

아래는 이렇게 만든 자격증명 두 건입니다. 한 가입자에게 인증수단 둘이 묶여 있습니다.

표의 한 줄이 곧 자격증명입니다. 로그인을 검사하는 쪽은 청구자가 댄 계정의 줄을 찾습니다. 상태가 활성인 줄의 값으로만 확인합니다. 둘째 줄은 정지 상태라 그 보안 키로는 로그인할 수 없습니다.

회원 가입과 로그인을 직접 만든 서비스라면 회원 테이블에 비밀번호 해시를 저장해 둡니다. 그 행 하나가 자격증명입니다. 가입자 머릿속의 비밀번호가 인증수단입니다.

자격증명의 수명 관리

제공자는 자격증명을 만든 뒤에도 손을 떼지 않습니다. 자격증명마다 상태를 붙여 두고 사건이 생길 때마다 바꿉니다. 아래 그림은 자격증명 하나가 거치는 상태입니다.

stateDiagram-v2
    [*] --> 활성: 등록
    활성 --> 정지: 분실 신고
    정지 --> 활성: 되찾음
    정지 --> 폐기: 못 찾음
    활성 --> 폐기: 유출 확인
    활성 --> 만료: 기한 지남
    폐기 --> [*]
    만료 --> [*]

등록을 마친 자격증명은 활성 상태로 시작합니다. 활성인 동안만 로그인에 쓰입니다.

가입자가 보안 키를 잃어버렸다고 알리면 제공자는 그 자격증명을 정지합니다. 되찾았다고 알리면 다시 활성으로 돌립니다. 끝내 못 찾으면 폐기합니다.

인증수단이 남의 손에 넘어간 것이 확인되면 제공자는 곧바로 폐기합니다. 폐기한 자격증명은 다시 살리지 않습니다. 가입자에게는 새 인증수단을 묶어 새 자격증명을 만들어 줍니다.

제공자는 자격증명에 기한을 둡니다. 기한이 있으면 오래전에 샌 수단이 끝없이 통하지 않습니다. 기한을 넘긴 자격증명은 만료됩니다.

기한이 다가오면 가입자는 아직 유효한 수단으로 로그인한 뒤 새 수단을 받습니다. 이 일이 갱신입니다. 만료되기 전에 새 자격증명으로 갈아타 두는 것입니다.

수단을 전부 잃은 가입자는 로그인으로 자기를 증명할 수 없습니다. 이런 가입자에게 새 수단을 묶어 주는 절차가 계정 복구입니다.

제공자는 가입 때 모아 둔 기록으로 본인인지 다시 확인합니다. 확인이 끝나면 새 수단을 묶어 줍니다. 이 확인에 쓰려고 제공자는 가입 기록을 자격증명이 살아 있는 동안 보관합니다.

검증자 · 신뢰 당사자와 나누는 일

로그인 한 번에는 역할이 셋 얽힙니다. 제공자는 그중 로그인 전에 일을 끝내 두는 쪽입니다. 나머지 둘은 로그인하는 순간에 일합니다.

검증자는 청구자가 인증수단을 정말 가졌는지 확인하는 역할입니다. 앞에서 로그인을 검사하는 쪽이라 부른 것이 검증자입니다. 청구자가 비밀번호를 내밀면 검증자는 자격증명에 적힌 해시와 대조합니다. 자격증명이 아직 활성인지도 봅니다.

신뢰 당사자는 검증자의 확인 결과를 받아 가입자를 자기 서비스에 들여보내는 역할입니다. 신뢰 당사자는 인증수단을 직접 보지 않습니다. 검증자의 결과만 믿습니다.

검증자가 이 결과를 담아 신뢰 당사자에게 건네는 메시지가 단언입니다. 단언에는 누가 언제 로그인에 성공했는지가 적힙니다.

세 역할을 한 표로 모으면 이렇습니다.

아래 그림은 가입 한 번과 로그인 한 번을 이어서 보입니다. 사용자 한 사람과 위 표의 셋이 등장합니다. 사용자는 가입할 때 신청자, 로그인할 때 청구자입니다.

sequenceDiagram
    participant 사용자
    participant 제공자 as 자격증명 서비스 제공자
    participant 검증자
    participant 신뢰당사자 as 신뢰 당사자
    사용자->>제공자: 가입을 신청한다
    Note over 제공자: 신원 증명
    제공자-->>사용자: 인증수단을 묶어 준다
    사용자->>검증자: 로그인하며 인증수단을 내민다
    검증자->>제공자: 자격증명 상태를 묻는다
    제공자-->>검증자: 활성이다
    검증자->>신뢰당사자: 단언을 보낸다

가입은 한 번이고 로그인은 여러 번입니다. 그림의 아래쪽 넷은 로그인할 때마다 되풀이됩니다. 제공자는 가입 때 남긴 기록으로 로그인마다 검증자의 물음에 답합니다.

검증자가 늘 제공자에게 묻는 것은 아닙니다. 인증서는 공개 키와 그 주인을 한 문서에 묶은 자격증명입니다. 가입자는 로그인할 때 이 문서를 함께 내밉니다.

제공자는 인증서를 내줄 때 서명을 붙입니다. 서명은 그 제공자만 만들 수 있는 표식입니다. 그래서 검증자는 제공자에게 묻지 않고 서명만 검사해도 기록이 진짜인지 압니다.

대신 폐기된 인증서를 걸러 내는 일이 따로 생깁니다. 서명은 폐기된 뒤에도 그대로 맞기 때문입니다. 검증자는 제공자가 내놓는 폐기 목록을 받아 두고 대조합니다. 이 목록이 인증서 폐기 목록입니다.

인증서를 발급하는 쪽은 인증 기관입니다. 인증 기관은 신청자를 확인한 뒤 인증서에 서명합니다. 필요하면 그 인증서를 폐기합니다. 하는 일이 제공자와 같아서, 인증서로 로그인하는 구성에서는 인증 기관이 이 역할을 맡습니다.

한 서비스가 역할을 겸하는 구성

세 역할이 늘 세 회사로 갈리는 것은 아닙니다. 한 서비스가 셋을 다 맡는 구성이 가장 흔합니다.

회원 가입과 로그인을 직접 만든 서비스를 떠올려 보면 됩니다. 가입 API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스)가 이메일을 확인하고 비밀번호 해시를 저장합니다. 이 부분이 자격증명 서비스 제공자입니다.

로그인 API 는 들어온 비밀번호를 해시해 저장된 값과 대조합니다. 이 부분이 검증자입니다. 로그인한 가입자에게 화면과 데이터를 내주는 나머지 코드가 신뢰 당사자입니다. 세 역할이 한 코드베이스 안에서 함수 몇 개로 나뉘어 있을 뿐입니다.

로그인을 바깥에 맡기면 역할이 회사 사이로 갈립니다. 회사 계정 시스템이나 소셜 로그인 서비스가 제공자와 검증자를 함께 맡습니다. 결과를 받아 쓰는 각 서비스가 신뢰 당사자입니다.

이렇게 제공자·검증자를 겸하면서 로그인 결과를 단언으로 내주는 서비스 전체를 신원 제공자라고 부릅니다. 이 편의 제공자는 신원 제공자 안에 든 한 역할입니다.

반대로 제공자의 일을 더 잘게 나누기도 합니다. 가입과 신원 증명만 떼어 다른 기관에 맡기는 구성입니다. 이 기관이 등록 기관입니다. 인증서 발급에서 인증 기관 앞단에 서서 신청자를 확인하는 기관을 흔히 이 이름으로 부릅니다.

제공자에 기대는 대가

제공자에 기대면 검증자가 신원을 따로 확인하지 않아도 됩니다. 대가는 가입 때 한 확인이 뒤의 모든 로그인에 그대로 물려 내려간다는 것입니다.

첫째, 검증자는 가입 때 확인한 것 이상을 보장하지 못합니다. 누구나 남의 이름으로 계정을 만들 수 있으면, 로그인에 보안 키를 요구해도 그 계정의 이름은 믿을 수 없습니다.

둘째, 계정 복구가 가장 약한 고리가 되기 쉽습니다. 로그인에 보안 키를 요구해도 분실 신고 뒤 이메일 하나로 새 수단을 받을 수 있다고 합시다. 공격자는 보안 키를 훔치는 대신 그 이메일을 노립니다. 복구 때 확인이 가입 때 확인보다 느슨하면 그 차이만큼 보호가 줄어듭니다.

셋째, 폐기가 모든 검증자에게 닿기까지 시간이 걸립니다. 검증자가 상태를 매번 묻지 않고 한동안 기억해 두거나 폐기 목록을 가끔만 받아 오면, 폐기한 자격증명이 그 사이 계속 통합니다.

넷째, 제공자에게 민감한 기록이 모입니다. 신분증 사본이나 인사 기록처럼 신원 증명에 쓴 자료를 복구에 쓰려고 보관하기 때문입니다. 제공자가 털리면 이 기록이 한꺼번에 샙니다.

이 역할을 의식해야 할 때

서비스가 가입 · 계정 복구 · 인증수단 추가 기능을 직접 만든다면 그 코드가 제공자 역할을 합니다. 이때 두 가지를 정해야 합니다. 가입 때 신원을 얼마나 꼼꼼히 확인할지와, 복구 때 그보다 느슨해지지 않게 할 방법입니다.

로그인을 전부 바깥 신원 제공자에 맡긴 서비스는 이 역할을 직접 맡지 않습니다. 가입 확인과 수단 관리는 바깥 쪽이 합니다. 서비스는 단언을 검사하는 신뢰 당사자로만 일합니다.

관련 항목

자격증명 서비스 제공자와 함께 로그인을 나눠 맡는 역할

검증자 · 신뢰 당사자 · 신원 제공자 · 등록 기관 · 인증 기관 · 신청자 · 가입자 · 청구자

자격증명 서비스 제공자가 만들고 관리하는 대상

자격증명 · 인증수단 · 보안 키 · 비밀번호 · 인증서 · 공개 키 · 개인 키 · 일회용 비밀번호

자격증명 서비스 제공자가 치르는 절차

신원 증명 · 계정 복구 · 키 로테이션 · 토큰 폐기 · 인증서 폐기 목록 · 비밀번호 해싱 · 해시 함수

자격증명 서비스 제공자를 정의하는 지침과 모델

NIST · 디지털 신원 · 신원 보증 수준 · 인증 보증 수준 · 공개 키 기반구조

자격증명 서비스 제공자의 기록에 기대는 로그인 방식

인증 · 인증과 인가 · 다중 인증 · 단언 · 연합 인증 · SSO · 소셜 로그인 · 패스키

자격증명 서비스 제공자와 이름이 헷갈리는 이웃

콘텐츠 보안 정책 · 암호 서비스 공급자 · 서비스 제공자