여러 소셜 공급자의 subject를 저장할 때 어떤 복합 고유 키가 필요하며 subject 재사용 문제는 어디까지 막을 수 있나요?

꼬리 질문을 독립 문항으로 확장했습니다. 원래 문항에서 맥락 보기 →

잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?

답변과 점검 포인트 펼치기답변 접기

구두 답변

정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.

공급자 안에서 유일한 subject는 다른 issuer의 같은 문자열과 구분해야 하므로 보통 issuer와 subject를 함께 외부 신원 키로 사용합니다. 이메일은 변경·공유될 수 있어 기본 연결 키로 대신하지 않습니다.

DB UNIQUE는 동일 조합의 중복 연결을 막지만 공급자가 실제로 subject를 재사용하지 않는다는 외부 약속 자체를 증명하지 못합니다. 공급자 이전·재등록·계정 삭제의 정책과 원본 신원 증거를 확인합니다. 다른 내부 계정에 붙은 신원을 자동으로 옮기지 않습니다.

이해가 드러나는 지점을 확인해 보세요.

공급자 안에서 유일한 subject는 다른 issuer의 같은 문자열과 구분해야 하므로 보통 issuer와 subject를 함께 외부 신원 키로 사용합니다. 이메일은 변경·공유될 수 있어 기본 연결 키로 대신하지 않습니다.
다른 내부 계정에 붙은 신원을 자동으로 옮기지 않습니다.

놓치기 쉬운 조건과 오해를 짚어 보세요.

다음 핵심 구분을 반대로 설명하거나 성립 조건을 생략한다: 공급자 안에서 유일한 subject는 다른 issuer의 같은 문자열과 구분해야 하므로 보통 issuer와 subject를 함께 외부 신원 키로 사용합니다.

하나 더 질문하며 이해의 범위를 넓혀 보세요.

득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.

답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.