必要なOpenID情報を保存する

Question

自分のサイトでOpenID認証を実装しようとしています。ここではシナリオです：
私は、ユーザーがちょうどのOpenID（ユーザがちょうどOpenIDプロバイダを訪問して確認していない得ることができ、電子メール、パスワードを使用してカスタムアカウントを作成する必要が。）、 を使用して

• ログインできるようにしたいです
• 電子メール/パスワードを介して（ユーザーがフォームに記入してサイトに登録した）
• 自分のアカウントにオープンIDを添付します（openids + 1アカウントのメール）。

私はオープン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. 

今、ユーザーがOpenIDを/カスタムメンバーシップを使用することによって、私はちょうど認証テーブルを見て、資格情報を探し、適切なユーザーを取得するかどうか、ログインすると。ユーザーがいない場合は、新しいユーザーを作成し、認証テーブルにエントリを追加します。

• 主な質問は：ProviderとLoginId OpenID認証を格納するための十分な（これらのフィールドに格納されているかを確認するには上記のコメントを参照）を格納していますか？追加のデータを保存して、ユーザーが戻ったときに私の保存データに基づいて認証できるようにする必要がありますか？

• これを実装する他の（より効率的な）アプローチをお勧めしますか？
  ありがとうございます。

Answer 1

ClaimedIdentifierをopenidユーザー用に格納します。プロバイダのアドレスではありません。主張識別子は、OpenIDプロトコルが検証するものがユーザにとって一意であり、潜在的にOpenIDプロバイダ間で移植性を提供するものです。

また、OpenID 2.0の主張識別子は、OpenID Connect（OpenID 2.0の未完成の後継者）によって廃止される可能性があるため、OpenIDプロバイダのエンドポイントURIとユーザーレコード内のプロバイダ。今のところではなくが認証フローの一部としてこれらを使用しますが、それらを記録することで、あなたが信頼する電子メールアドレスを後で判断することができます（つまり、Googleが主張する電子メールアドレスが信頼できると判断したとします）。ユーザーはその確認済みの電子メールアドレスを使用して自分のアカウントをOpenID Connectに移行できます。これにより、ウェブサイトの領域（通常はhttp://yourdomainname.com）が変更され、GoogleのユーザークレームIDがすべて変更される危険性が軽減されます。これは本当に自分のメールアドレスから悲劇的にしか回復できません。

また、さまざまな認証タイプに異なるテーブルを使用することをお勧めします。ここにはいくつかの利点があります。最も重要なのは、アーキテクチャ上、Webサイトにセキュリティホールを導入して、誰かがOpenIDをusernameフィールドに入力して空白のパスワードを入力し、実際の認証が行われずにデータベースの一致とログインが可能になります。第2に、すべてのユーザーに対して「認証」テーブルを横方向に拡大するのではなく、3番目の認証メカニズムを追加する場合に、より柔軟なモデルを提供します。たとえば、OAuth 2.0と "OpenID Connect"は、何年も前からサポートを追加したときに新しいタイプの認証を導入し、新しいタイプのデータを処理するための新しいテーブルを追加する方が適しているようです。

Answer 2

私たちは単にopenidの主張URLを保存します。プロバイダーからユーザー名などの追加情報を要求することができます。最も重要なことは、メンバーシップと認証を分離することです。

私たちのスキーマは

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

Users 
----- 
Username 
Password 

たProfiles.UserIdは、彼らが登録された方法に応じて、単にユーザ内部ユーザ名またはそのOpenIDの主張のURLのいずれかを格納する文字列プロパティです。

認証に成功すると（内部ユーザー名/パスワードまたは外部プロバイダを使用）、内部ユーザー名またはクレームURLのいずれかを使用して認証Cookieを設定するだけです。ユーザのプロファイルを取得することは、（UserId == User.Identity.Name）のところでプロファイラを見つけることだけです。

これは、ユーザーが任意の時点でどのように認証するかを変更することができるという利点があります（おそらく、内部アカウントに切り替えたり、別のプロバイダを使用するなど）。