CASまたはOAuthを使用したSSO？

シングルサインオンにCASプロトコルまたはOAuth +一部の認証プロバイダーを使用する必要があるのか​​と思います。

シナリオ例：

1. ユーザーが保護されたリソースにアクセスしようとしましたが、認証されていません。
2. アプリケーションはユーザーをSSOサーバーにリダイレクトします。
3. 認証されている場合、ユーザーはSSOサーバーからトークンを取得します。
4. SSOは元のアプリケーションにリダイレクトします。
5. 元のアプリケーションは、SSOサーバーに対してトークンをチェックします。
6. トークンに問題がなければ、アクセスが許可され、アプリケーションはユーザーIDを認識します。
7. ユーザーはログアウトを実行し、接続されているすべてのアプリケーションから同時にログアウトされます（シングルサインアウト）。

私が理解している限り、それはまさにCASが発明したものです。CASクライアントは、認証サービスを使用するためにCASプロトコルを実装する必要があります。今、私はクライアント（コンシューマー）サイトでCASまたはOAuthを使用することを考えています。OAuthはCASのその部分の代替品ですか？新しい事実上の標準としてのOAuthを優先すべきですか？ユーザー名/パスワード、OpenID、TLS証明書などのさまざまな方法をサポートするCASの認証部分の使いやすい（Sun OpenSSOではありません！）置き換えはありますか？

環境：

• さまざまなアプリケーションがSSOサーバーの認証に依存し、セッションのようなものを使用する必要があります。
• アプリケーションは、GUI Webアプリケーションまたは（REST）サービスにすることができます。
• SSOサーバーは、ユーザーIDを提供する必要があります。これは、中央のユーザーインフォメーションストアからロールや電子メールなどのユーザーに関する詳細情報を取得するために必要です。
• シングルサインアウトが可能である必要があります。
• ほとんどのクライアントはJavaまたはPHPで記述されています。

OAuthの後継となる可能性のあるWRAPを発見しました。これは、Microsoft、Google、Yahooによって指定された新しいプロトコルです。

補遺

OAuthは、SSOを実装するために使用することもできますが、OpenIDのようなSSOサービスと一緒にのみ使用できるように認証用に設計されていないことを知りました。

OpenIDは「新しいCAS」のようです。CASにはOpenIDが欠落する機能（シングルサインアウトなど）がいくつかありますが、特定のシナリオで欠落しているパーツを追加することは難しくありません。OpenIDは広く受け入れられていると思います。OpenIDをアプリケーションまたはアプリケーションサーバーに統合することをお勧めします。CASもOpenIDをサポートしていることは知っていますが、CASはOpenIDを必要としないと思います。

OpenIDはCASの「後継者」または「代用」ではありません。意図と実装は異なります。

CASは認証を一元化します。すべての（おそらく内部の）アプリケーションがユーザーに単一のサーバーにログインするように要求する場合に使用します（すべてのアプリケーションは単一のCASサーバーを指すように構成されています）。

OpenIDは認証を分散化します。アプリケーションがユーザーに必要な認証サービスへのログインを受け入れるようにする場合に使用します（ユーザーはOpenIDサーバーアドレスを提供します。実際、「ユーザー名」はサーバーのURLです）。

上記のいずれも承認を処理しません（拡張機能やカスタマイズを行わない場合）。

OAuthは承認を処理しますが、従来の「USER_ROLESテーブル」（ユーザーアクセス）の代わりにはなりません。サードパーティの承認を処理します。

たとえば、アプリケーションをTwitterと統合したいとします。ユーザーがデータを更新したり、新しいコンテンツを投稿したりすると、ユーザーはそれを自動的にツイートできるようになります。ユーザーのパスワードを取得せずに、ユーザーに代わってサードパーティのサービスやリソースにアクセスしたい（ユーザーにとって明らかに安全ではない）。アプリケーションがTwitterにアクセスを要求し、ユーザーが（Twitterを介して）認証を行うと、アプリがアクセスできるようになります。

したがって、OAuthはシングルサインオンに関するものではありません（CASプロトコルの代替でもありません）。ユーザーがアクセスできるものを制御することではありません。それはさせる程度であるユーザーをどのように制御することが彼らの資源が第三者によってアクセスすることができます。2つの非常に異なるユースケース。

あなたが説明した文脈では、CASはおそらく正しい選択です。

[更新しました]

つまり、ユーザーのIDを保護されたリソースと見なす場合は、OAuthを使用してSSOを実装できます。これは、基本的には「GitHubでサインアップする」などです。おそらくプロトコルの本来の意図ではありませんが、それは可能です。OAuthサーバーを制御し、アプリがそれだけで認証するように制限する場合、それはSSOです。

ただし、ログアウトを強制する標準的な方法はありません（CASにはこの機能があります）。

私はそれをこのように考える傾向があります：

ユーザー認証システムを制御または所有していて、一元化された認証を必要とする異種のサーバーとアプリのセットをサポートする必要がある場合は、CASを使用します。

所有/サポートしていないシステム（Google、Facebookなど）からのユーザー認証をサポートする場合は、OAuthを使用します。

OpenIDは認証プロトコルであり、OAuthおよびOAuth WRAPは認証プロトコルです。ハイブリッドOpenID拡張と組み合わせることができます。

手元のアプリケーションに完全には適合していなくても、勢いのある標準（サポートの利用可能性が高く、サードパーティが関与しやすい）に基づいて構築する人々を強く望みます。この場合、OAuthにはCASではなく勢いがあります。OAuthで実行する必要があることのすべてまたは少なくともほぼすべてを実行できる必要があります。将来のある時点で、OAuth WRAPは物事をさらに簡素化する必要があります（ベアラートークンを使用して暗号化をプロトコルレイヤーにプッシュすることにより、ある程度のトレードオフが生じます）が、まだ初期段階であり、それまでの間、OAuthおそらくうまくいきます。

最終的に、OpenIDとOAuthを使用することを選択した場合、より多くの言語に対応するライブラリが増え、システムとの統合が必要な他のユーザーが利用できるようになります。また、プロトコルを確認する目玉が多くなり、想定どおりに実際に安全であることを確認します。

私にとって、SSOとOAuthの本当の違いは認証です。OAuth を実装するサーバーは明らかに認証を持っているためです（クライアントアプリでOAuthを実行するには、google、openId、またはfacebookにログインする必要があります）。

SSOでは、パワーユーザー/システム管理者が「SSOアプリ」でアプリケーションに最終ユーザーアクセスを事前に許可しますOAuthでは、最終ユーザーが「OAuthアプリ」で「データ」へのアプリケーションアクセスをアプリケーションに許可します

OAuthプロトコルをSSOサーバーの一部として使用できなかった理由がわかりません。フローから許可画面を取り出し、OAuthサーバーにバッキングデータベースから許可を検索させるだけです。

古い投稿ですが、これは役に立つかもしれません：

CAS 3.5はクライアントおよびサーバーとしてoAuthをサポートします。参照：https : //wiki.jasig.org/display/CASUM/OAuth