私はSSOメカニズムに取り組んでいます。私はそれを設定し、ログイン画面で認証サーバーを作成しました。SSO は次のように機能するはずです (その時点までは既に機能しています)。
- クライアント アプリにアクセスし、ユーザーがログインしていない場合、SSO Auth レルムにリダイレクトします
- ユーザーがログインしていないときの SSO Auth レルムで、ログイン画面を表示する
- ログイン後、セッション変数を作成し（またはユーザーがすでにログインしている場合-セッション変数が存在する場合）、セッションに保存されたトークンでリダイレクトします
- クライアントアプリに戻ったら、トークンを取得してセッションに保存し、SSO 認証レルムから user_id をリクエストします。
cURL - クライアントアプリでユーザーがログインしている場合、各リクエストでポイントを繰り返して
4.、ユーザーがまだログインしていることを確認し、サーバーが誤った応答で応答したときにクライアントでログアウトを実行します
最初の 3 つのポイントはうまく機能していますが、ポイント 4 (および 5 など) に問題があります。これは、cURL が SSO Auth レルムを要求すると、そこにセッションが存在しない (または cURL 要求に対して新しいセッションが作成される) ように見えるためです。 .
したがって、私は尋ねたい：
- SSO Auth レルム アプリケーションが既存のセッションにアクセスし、cURL 応答内の情報をクライアント アプリに返す方法を教えてください。
- または、このチェックを行うより良い方法は何ですか?
明らかではないいくつかの情報：
- すべてのクライアント アプリケーションと SSO Auth レルム アプリケーションには独自のセッションがあります。
- チェックを行う理由は、ユーザーが別のクライアント アプリケーションでログオフしていないか (SSO 認証レルムでセッションが期限切れになっていないか) をチェックするためです。
- SSO Authレルムとは、ユーザーのログインを担当するアプリケーションを意味します
- これは巨大なセキュリティ リークになるため、ログイン後にトークンを直接転送することは
user_idできません。ランダムなトークンと既存のユーザー ID を含む URL を使用してクライアント アプリケーションを開くだけで、任意のユーザーとしてログインできます。
編集：今のところ、SSO認証レルムのPHPSESSIDをトークンとして使用して問題を解決しました。このようにPHPSESSID=TOKENして、cURL で Cookie を設定し、リクエストが既存のセッションにアクセスできるようになりましたが、レルムの PHPSESSID を URL リダイレクトで見られるトークンとして使用するという考えは好きではありません... より良い解決策を知っている人はいますか?