[Wiki] OpenID

1. 설명

• OpenID 재단이 관리하는 인증 수단

항목	설명	예
분산형 디지털 신원 시스템	사용자가 다양한 웹사이트에 하나의 계정으로 로그인할 수 있음
ID 형식	- URL - XRI	https://me.example.com/ =alice @company*bob
Service Discovery	사용자가 입력한 OpenID 식별자를 통해 ID 제공자를 자동으로 찾는 프로토콜	Yadis 프로토콜

 

Service Discovery) Yadis 프로토콜 동작 방식

단계	설명
1	사용자가 OpenID URL 입력
2	RP가 HTTP 요청 → X-XRDS-Location 헤더나 <meta> 태그 탐색
3	XRDS 문서 위치 확인 후 해당 URL에 접근
4	XRDS 문서(XML)를 파싱하여 ID Provider 주소 확인
5	인증 요청은 이 주소로 전송

 

2. 구성 요소

용어	설명
최종 사용자 (End User)	인증을 요청하는 사람	로그인하려는 사용자
ID (Identifier)	사용자의 신원을 나타내는 값	URL XRI
ID 제공자 (Identity Provider, IdP)	사용자의 ID를 관리하고 인증을 수행하는 주체
Relying Party (RP)	인증을 요청하고 그 결과를 검증하는 웹사이트 또는 서비스
서버 / Server-Agent	ID 검증 요청을 처리하는 서버	ID 제공자가 운영하는 서버 사용자 소유 블로그
User-Agent	사용자가 웹사이트에 접근할 때 사용하는 소프트웨어	웹브라우저

 

3. 특징

인증 방식

• checkid_immediate: 사용자 개입 없이 서버 간 인증 (자동화 방식)
• checkid_setup: 사용자 직접 인증 (브라우저 통해 진행) → 일반적으로 이 방식이 많이 사용됨

 

 

인증서 유효성 검증

• OpenID에서 인증 후 받은 응답에 있는 인증서가 신뢰할 수 있는 IdP로부터 온 것인지 검증하는 방식

구분	Stateful 방식	Stateless 방식
검증 방법	사전 공유한 키로 직접 서명 검증	check_authentication 요청으로 검증 (인증 요청이 필요할 떄마다 idP에 직접 확인 요청)
성능	빠름 (로컬 처리)	느림 (네트워크 왕복)
보안키 저장	필요 (association 저장)	불필요
서버 상태 유지	필요 (stateful)	불필요 (stateless)
별칭	Smart Mode	Dumb Mode

 

4. 장단점

장점

항목	설명
단일 ID 로그인	사용자는 하나의 ID(OpenID) 로 다양한 웹사이트에 로그인할 수 있어, 사이트마다 별도 계정 만들 필요 없음
신뢰하는 ID Provider 사용	사용자는 자신이 신뢰하는 ID 제공자(IdP) 를 통해서만 인증하면 됨
개발 사이트는 인증만 검증	서비스 제공 사이트(RP)는 인증 결과만 검증하면 되므로, 자체 사용자 인증 로직이 단순해짐
유연한 인증 구조	특정 인증 수단을 강제하지 않기 때문에 다양한 인증 방식 지원 가능 (예: 비밀번호, OTP 등)

 

단점

항목	설명
인증 강도 편차	인증 강도의 일관성이 없음 (ID Provider마다 사용하는 인증 방식이 다름)
보안 민감 서비스 부적절	고보안이 필요한 서비스에는 적합하지 않을 수 있음 (금융, 의료, 전자상거래 등)
신뢰 수준 판단 어려움	RP는 IdP의 인증 정책을 상세히 알 수 없음 (사용자가 얼마나 안전하게 인증받았는지 판단하기 어려움)
사용자 경험의 일관성 부족	IdP마다 인증 UI, 절차가 다름

 

5. 작동 방식

checkid_setup

1. 사용자 입력
   • 사용자가 오픈아이디를 입력하고 로그인 시도함 (예: alice.openid-provider.org)
2. ID 제공자(idP) 탐색
   • Relying Party(RP)는 해당 URL의 HTML 또는 XRDS(Yadis) 문서를 조회해
   • 이 오픈아이디를 관리하는 ID 제공자 주소(idP endpoint) 를 찾아냄
3. 리다이렉트
   • RP는 사용자의 브라우저를 해당 idP의 인증 페이지로 리다이렉트
4. 사용자 인증
   • 사용자는 idP에서 비밀번호 등으로 인증
   • idP는 사용자가 신뢰하는 Relying Party 주소인지 물어보기도 함
5. 인증 결과 전송
   • 인증이 성공하면 idP는 사용자의 브라우저를 RP의 callback URL로 리다이렉트함  (예: return_to)
   • 인증 결과를 함께 전달 (signed response)
6. 검증
   • RP는 이 signed response가 정말 idP에서 온 것인지 검증 (shared secret 또는 check_authentication)
7. 로그인 처리
   • 검증 성공 시 사용자 로그인 처리 (혹은 회원가입 유도)

 

 

 

출처

• Wiki - OpenID