ドメインでホストされているアプリがあります。すべてのユーザーは、最初に POST フォームからログインする必要があります。ログインが完了すると、フォームは自動的に当サイトのダッシュボード ページにリダイレクトされます。
一部のクライアントが独自のログイン フォームを (サイト上で) ホストし、アプリに投稿できるようにすることは可能ですか? クロスドメイン投稿は悪い習慣と見なされますか? 注意すべき落とし穴はありますか？最後に、私たちのサイトは常に HTTPS で実行されますが、クライアント サイトはそうでない可能性があるため、SSL はどのように処理されますか? これはiframeで回避できますか?
あなたが再発明しようとしているのはopenidと呼ばれます。
あなたがしなければならないことは、openid サービスを提供することです。そうすれば、ユーザーは自分の openid サーバーに接続する独自のログインフォームを作成できます。
私はそのようなサイトの素晴らしい例を持っています: http://www.stackoverflow.comは、Google などを openid サービスとして使用してログインし、独自のログインフォームを作成します。
あなたがやろうとしていることは、一般的にシングルサインオン(SSO) と呼ばれています。これは、さまざまなテクノロジを使用して実装できます。
一般的な考え方は、ユーザーが使用する実際のサービスを提供するサービス プロバイダー (SP) (リソース プロバイダーとも呼ばれる)を、ユーザーの ID が検証されるID プロバイダー (IdP)から分離することです。 .
simplePHPライブラリは、SAML、Shibboleth (これも SAML ベース)、OpenID などの多くの SSO 標準を使用して、IdP と SP の両方の認証レイヤーの実装を提供します。
標準を使用している場合、サービス用に選択したものと同じ実装を使用して IdP を実装する必要はないことに注意してください。たとえば、Shibboleth ライブラリを使用して IdP を Java に実装し、それを simplePHP を使用する SP と組み合わせて使用することができます。
これらの手法のどれを使用するかは、認証後に必要な情報の種類 (追加の属性が必要な場合など) や、IdP と SP 間の信頼の管理方法によって異なります。
通常、単純な OpenID システムは、SP の観点からはかなり簡単に統合できますが、ユーザーについて主張できることはかなり限られています。対照的に、Shibboleth には、どの SP がどのユーザー属性を認識できるか、およびどの IdP が解放するかどうかを指定するための多くのオプションがありますが、より実質的なインフラストラクチャが必要です。相互のアサーションを信頼するために使用する X.509 証明書を含むメタデータ構成のセット。
認証は管理境界の外で行われるため、ユーザーがどのように認証されるかを実際に制御することはできません (これが Shibboleth フェデレーションなどのより正式な合意の一部でない限り)。OpenID プロバイダーは、サービスが HTTPS を必要とする場合でも、プレーン HTTP 経由でユーザーを認証できる可能性があります。(そうは言っても、ほとんどの本格的な OpenID プロバイダーはそれを安全に行っており、とにかく信頼できるものを選択するのはユーザー次第です。)
IdP ページをサービスに埋め込まないでください。代わりに、ユーザーを IdP ページに移動させます。認証システムを (ユーザーに関する限り) 安全にするためには、ユーザーがパスワードを入力している内容を確認できることが不可欠です。iframe を使用することで、実際のサイトを効果的に隠すことができます (ロゴはつかみやすい/偽造しやすい)。( StackExchange OpenID プロバイダーには、その点でいくつかの問題があります。)