複数の無関係な Web サイトで同じユーザーを一意に識別することに依存する、Web サイト用のバックエンド (RESTful) サービスがあります。一意の識別子として電子メール アドレスを使用してきましたが、特に OpenID 認証がそれらの Web サイトで使用されている場合、すべての Web サイトで電子メール アドレスが常に使用されているわけではありません。
では、OpenID は、(ユーザーが同じ OpenID で認証する場合) 複数の依拠当事者間で同じになる一意の識別子を提供しますか?
もしそうなら、複数の無関係な Web サイトがそれぞれ同じ OpenID ユーザーを持っている場合に同じ ID を提供することが目標である場合、一連の独立した Web サイトに各ユーザーのユーザー ID として私たちを提供するように指示するにはどうすればよいでしょうか?
また、目標は、API を使用する開発者にとってこれをできるだけ簡単にすることです。したがって、これを既に解決している優れた API ドキュメントを知っている場合は、そのドキュメントへのリンクが非常に役立ちます。
あなたのWebサービスやそれが書かれている言語について何も知らなければ、私の答えがどれほど役立つかはわかりません。かなり一般的で技術的ではないからです.
識別/承認リクエストに応答する OpenID プロバイダーは、「要求された ID」と「アイデンティティ」、および要求された「属性交換」で応答します。属性交換情報は、電子メール/ユーザー名/言語/実名など、探しているものである可能性があります。
Google (OpenID プロバイダーとして) は適切な数の属性交換情報のクエリをサポートしており、ドキュメントでリストを提供しています: https://developers.google.com/accounts/docs/OpenID#Parameters
OpenID ID はユーザーに対して一意である必要がありますが、同じプロバイダーから発行された場合でも、別の Web サイトに対してユーザーを相互識別できない場合があります。(これは、発行先の RP に固有の直接 ID にすることができます)。詳細については、こちらをご覧ください: is openid.claimed_id static?
以上のことから、API の設計者として、Web サービスを使用するために特定の情報 (電子メール アドレスなど) が必要であると定義することは完全に合理的です。そして、Webサービスを使用して何らかの方法でその情報を取得したい当事者に任せます（ユーザーに直接尋ねるか、属性交換などを介して）。
OpenID の詳細については、彼らの Web サイト、特に仕様とライブラリを参照してください。 http://openid.net/specs/openid-authentication-2_0.html http://openid.net/developers/libraries/
出発点として使用するための優れたドキュメントを備えたライブラリには、次のものがあります。
OpenID 認証を直接実装することは、バックエンド Web サービスには適用できません。これは、エンド ユーザーが関与しない (つまり、資格情報を提供できない) ためです。
さまざまなサード パーティの Web サイトで同じユーザーを識別するという要件を満たすには、OpenIDプロバイダーになる必要がある場合があります。次に、ユーザーが管理する OpenID プロファイルにリンクするサード パーティの Web サイトの機能を許可するための追加の API を提供します。
ID の実際のプロバイダーでなくても... OpenID ID をサードパーティと共有することは、潜在的なセキュリティ/プライバシーの問題になるか、少なくとも OpenID の仕様に反する可能性があります (これは、交換を RP とOP）。あなたがやりたいことの範囲を超えているかもしれませんが、OpenID プロバイダーであることは、ユーザーが明示的にオプトインする必要があるため、少なくともプライバシーの問題の多くを取り除くでしょう.
ユーザーが直接操作せずに、複数のサード パーティの Web サイト間でユーザーを一意に識別する API を認識していません。私が作成したほとんどの Web サービスでは、(ユーザーが認識している) 直接のユーザー資格情報を提供するか、ユーザーを特定のクライアントに固有のものとして識別するだけで済みました。後者の場合、ユーザー認証が必ずしも必要ではない場合、クライアントはブランケット認証を行い、ユーザーを追跡するために独自の一意の ID を提供して、Web サービスが実際にユーザーを構成するものを認識できないようにすることができます。残念ながら、要件はこれらの一般的なシナリオに適合していないようです。
API を設計する際に考慮すべき最後の 1 つのこと...
一意に識別可能な情報 (電子メール アドレスなど) を第三者に提供すると、インターネットのプライバシー リングで眉をひそめる可能性があります。特に、交換（広告/直接支払い/など）から得られる金銭的利益がある場合、または情報の使用が不明/安全でないか、そうでなければ歓迎されない場合. http://www.ehow.com/about_5332990_legal-sell-email-list.html http://www.aclu.org/technology-and-liberty/internet-privacy
ターゲット クライアント (Web サービスのコンシューマー) の用語に適切な専門用語が含まれていること、またはユーザーがサービスへの送信をオプトアウトできる十分な権限をユーザーに提供できることを確認する必要がある場合があります。そして、あなたが情報を使って何をしているのかを明確にしてください...
このような問題は、API の受け入れを妨げている可能性があるため、検討する価値があります。