SCENARIOサブドメイン（サブドメインが2いる）
あり3つのドメイン認証メカニズム＆セッションメンテナンス
サイト1
サイト2
API
ISSUEサイト1のみがサイト1にして、ログインページに
ユーザーログを持っている
とhログインしたユーザーとしてsite2に行くことができるようにします。ここで、site2は、認証（site1によって提供される必要があります）を含むすべての操作に対してREST APIサーバーを使用します。
これに最も適した方法は何ですか？トークンの代替対
セッション：
セッションクッキー：サイト1には、ユーザーを認証し、ユニークなセッションIDクッキーで識別されるサーバーセッションを作成します。それは、クッキーが簡単にドメイン間で共有することができないために廃棄され、それはまた、サーバーのセッション
認証トークンを共有暗示されています。サイト1はユーザ認証成功後にランダムなトークンを生成し、サイトに2サイト2つの店舗をリダイレクトトークンを使用してAPIを呼び出します。アプリケーションがフォームベースの場合は、各ユーザーのセッションを使用してSPA（シングルページアプリケーション）またはサーバー側を構築する場合、トークンはクライアント側に格納できます。トークン戦略について
、あなたが使用することができます。
不透明トークンを：サイト1.両方のサイト2とAPIでユーザに割り当てられ、保存されたランダムな文字列をサイト1問い合わせる必要があります彼らはそれがアクティブで、誰にそれが
JSONウェブトークン（JWT）に対応しているかどうかを確認するためにトークンを受信します。トークンは、自己完結型で、ユーザーIDといくつかのothed CLAを含み私たちのような興味のIMは、満期時間や聴衆。トークンはサイト1の秘密鍵で署名されているため、改ざんから保護されています。サイト2とAPIは、site1にオンラインで照会せずにJWTを検証でき、サーバーストレージは不要です。この場合、非対称キーペアprivate-public（RSA）が必要です。トークンは、秘密鍵で署名し、公共
がをまとめると検証される：JWTは、JWTがスライスされている場合、それは良いでしょう、あなたの開発を簡素化し、サーバー間連携を低減し、より少ないリソース
が必要ですfrom site1 ----- ** Site1 ** - thatsme.orgの下にユニークな_UserId_（apiの公開鍵で暗号化されています）を配置します............. ** Site2 ** - そのクッキーにアクセスし、セッションが存在しない場合は、apiサーバーに転送します。... ** api ** - 復号化プライベートキーを持つユーザーIDを取得し、site2セッションに格納されているjwtを作成します。... ** Site2 ** - APIサーバー –
へのすべてのapi呼び出しでjwtを使用します。暗号化はセキュリティを追加しません。暗号化されたIDまたは暗号化されていないIDを盗むユーザーは、いつでもそのユーザーを偽装する可能性があります。システム全体のキーを変更する必要があります。 site1がJWTを生成すると便利です – pedrofb