필요한 OpenID 정보 저장

Question

내 사이트에 OpenID 인증을 구현하려고합니다. 여기에 시나리오는 다음과 같습니다
나는 사용자가 (. 바로 오픈 ID 공급자를 방문하여 확인하지 얻을 수있는 이메일 암호를 사용하여 사용자 정의 계정을 생성 할 필요 사용자),

• 로그인 그냥 오픈 아이디를 사용 할 수있게하려면
• 이메일/패스워드를 통해 (사용자가 양식을 작성하여 사이트에 등록)
• 오픈 아이디를 계정에 첨부하십시오 (하나의 계정에 대해 openids + 이메일).

이제 공개 ID로 저장할 자격 증명을 알 수 없습니다. DB 스키마에 대해 확실하지 않습니다. 다음은 데이터베이스 스키마가있다 :

Table: Users 
UserId => PK 
... => Custom info. Not related to authentication. 

Table: Authentication 
AuthenticationId => PK 
LoginId => (when custom site membership => email address) (when openId => openid unique address) 

UserId => FK to Users. 
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address) 
Password => filled when using custom membership. empty when using open id. 

을 이제 사용자가 여부를 오픈 ID/사용자 지정 멤버 자격을 사용하여 로그인 할 때, 난 그냥 인증 테이블을보고 자격 증명을보고 적절한 사용자를 얻을. 사용자가 없으면 새 사용자를 만들고 인증 테이블에 항목을 추가합니다.

• 주요 질문 : Provider 및 LoginId 오픈 ID 인증을 저장하기위한 충분한 (이 필드에 저장되는 것을 볼 수 위의 설명 참조)에 저장되어 있습니까? 사용자가 반환 할 때 저장된 데이터를 기반으로 사용자를 인증 할 수 있도록 추가 데이터를 저장해야합니까?

• 이것을 구현하는 다른 (더 효율적인) 방법을 제안 하시겠습니까?
  감사합니다.

Answer 1

ClaimedIdentifier은 공급자 주소가 아닌 openid 사용자 용으로 저장하십시오. Claimed Identifier는 OpenID 프로토콜이 사용자에게 고유 한 것으로 검증하는 것이며 OpenID Provider 전반에서 잠재적으로 이식성을 제공합니다.

또한 OpenID 2.0의 소유권이 주장 된 식별자는 OpenID Connect (OpenID 2.0의 미완료 후계자)에 의해 사용 중지 될 수 있으므로 OpenID Provider Endpoint URI와 해당 OpenID가 주장하는 전자 메일 주소를 기록하는 것이 가장 좋습니다. 공급자는 사용자 레코드에 있습니다. 지금은 이 아니며이 인증 흐름의 일부로 사용되지만 기록을 통해 나중에 신뢰할 수있는 이메일 주소를 결정할 수 있습니다 (예 : Google이 주장하는 이메일 주소가 신뢰할 수 있다고 판단한 경우). 사용자는 확인 된 이메일 주소를 사용하여 OpenID Connect로 계정을 이전 할 수 있습니다. 이것은 또한 귀하의 웹 사이트 영역 (일반적으로 http://yourdomainname.com)이 변경되어 귀하의 모든 Google 사용자 소유권이 주장 된 식별자가 변경 될 수있는 위험을 완화합니다. 이는 귀하의 이메일 주소를 통해 실제로 비극적으로 복구 될 수 있습니다.

다른 인증 유형에 대해 다른 테이블을 사용하는 것이 좋습니다. 여기에 몇 가지 장점이 있습니다. 가장 중요한 것은 구조적으로 웹 사이트에 누군가가 (예를 들어) 사용자 이름 필드에 OpenID를 입력하고 빈 암호를 입력 할 수있는 보안 구멍을 도입하는 것이 구조적으로 어렵다는 것입니다. 실제 인증없이 데이터베이스 일치 및 로그인 둘째, 모든 사용자가 '인증'테이블을 가로로 확장하는 대신 세 번째 인증 메커니즘을 추가하려는 경우보다 유연한 모델을 제공합니다. 예를 들어, OAuth 2.0과 "OpenID Connect"는 수년 동안 지원을 추가 할 때마다 새로운 유형의 인증을 도입 할 것이며, 새로운 유형의 데이터를 처리하기위한 새로운 테이블을 추가하는 것이 더 적합 할 것입니다.

Answer 2

우리는 단지 openid 클레임 URL을 저장합니다. 사용자 이름과 같은 공급자로부터 추가 정보를 요청할 수 있습니다. 가장 중요한 것은 회원 자격과 인증을 분리하는 것입니다.

우리의 스키마는

Profiles 
-------- 
UserId 
FirstName 
LastName 
etc. 

Users 
----- 
Username 
Password 

Profiles.UserId들이 등록 방법에 따라 사용자가 내부 사용자 이름 또는 오픈 아이디 청구 URL 중 하나를 저장하는 문자열 속성은 간단했다.

내부 사용자 이름/암호 또는 외부 공급자를 사용하여 인증을 완료하면 내부 사용자 이름이나 소유권 주장 URL을 사용하여 인증 쿠키를 설정하기 만합니다. 사용자 프로필을 얻는 것은 (UserId == User.Identity.Name) 여기서 프로파일 러를 찾는 것입니다.

이렇게하면 사용자가 언제든지 (예 : 내부 계정으로 전환하거나 다른 제공 업체를 사용하여) 인증 방법을 변경할 수있는 장점이 있습니다.