CASまたはOAuthを使用したSSOですか？
CAS プロトコルまたは OAuth +シングルサインオン用の認証プロバイダーを使用する必要があるのだろうか。
シナリオ例：
- ユーザーが保護されたリソースにアクセスしようとしましたが、認証されていません。
- アプリケーションは、ユーザーをSSOサーバーにリダイレクトします。
- 認証されている場合、ユーザーはSSOサーバーからトークンを取得します。
- SSOは元のアプリケーションにリダイレクトします。
- 元のアプリケーションは、SSOサーバーに対してトークンをチェックします。
- トークンに問題がなければ、アクセスが許可され、アプリケーションはユーザーIDを認識します。
- ユーザーはログアウトを実行し、接続されているすべてのアプリケーションから同時にログアウトされます（シングルサインアウト）。
私の知る限り、それはまさにCASが発明したものです。 CASクライアントは、認証サービスを使用するためにCASプロトコルを実装する必要があります。今私は、クライアント（消費者）サイトでCASまたはOAuthを使用することを考えています。 OAuthはCASのその部分の代替品ですか？新しい事実上の標準としてOAuthを優先すべきですか？ユーザー名/パスワード、OpenID、TLS証明書などのさまざまな方法をサポートするCASの認証部分の使いやすい（Sun OpenSSOではありません！）代替品はありますか？
状況：
- さまざまなアプリケーションは、SSOサーバーの認証に依存し、セッションのようなものを使用する必要があります。
- アプリケーションは、GUI Webアプリケーションまたは（REST）サービスです。
- SSOサーバーはユーザーIDを提供する必要があります。これは、中央ユーザー情報ストアからロール、電子メールなどのユーザーに関する詳細情報を取得するために必要です。
- シングルサインアウトが可能になります。
- ほとんどのクライアントは、JavaまたはPHPで記述されています。
WRAPを発見した で、これはOAuthの後継になる可能性があります。これは、Microsoft、Google、およびYahooが指定した新しいプロトコルです。
補遺
OAuthは、SSOを実装するために使用することもできますが、OpenIDなどのSSOサービスと一緒に使用する場合でも認証用に設計されていないことを学びました。
OpenIDは私にとって「新しいCAS」のようです。 CASにはOpenIDにない機能（シングルサインアウトなど）がありますが、特定のシナリオで不足している部分を追加するのは難しくありません。 OpenIDは広く受け入れられており、OpenIDをアプリケーションまたはアプリケーションサーバーに統合することをお勧めします。 CASはOpenIDもサポートしていることは知っていますが、CASはOpenIDに不可欠ではないと思います。
OpenIDはCASの「後継」または「代替」ではなく、意図と実装が異なります。
CAS centralizes認証。すべての（おそらく内部の）アプリケーションがユーザーに単一のサーバーへのログインを要求する場合に使用します（すべてのアプリケーションは単一のCASサーバーを指すように構成されます）。
OpenID 分散化認証。ユーザーが望む認証サービスへのユーザーログインをアプリケーションに許可する場合に使用します（ユーザーはOpenIDサーバーアドレスを提供します-実際には、「ユーザー名」はサーバーのURLです）。
上記のいずれも承認を処理しません（拡張機能やカスタマイズなし）。
OAuthは承認を処理しますが、従来の「USER_ROLESテーブル」（ユーザーアクセス）の代替ではありません。サードパーティの承認を処理します。
たとえば、アプリケーションをTwitterと統合したい場合、ユーザーは、データを更新したり新しいコンテンツを投稿したりするときに自動的にツイートを許可することができます。パスワードを取得せずに、ユーザーに代わってサードパーティのサービスまたはリソースにアクセスしたい（これは明らかにユーザーにとって安全ではありません）。アプリケーションはTwitterにアクセスを要求し、serが（Twitterを介して）承認すると、アプリがアクセスできるようになります。
したがって、OAuthはシングルサインオンに関するものではありません（CASプロトコルの代わりでもありません）。 yoユーザーがアクセスできるものを制御することではありません。 serにサードパーティによるtheirリソースへのアクセス方法を制御させることです。 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を使用することを選択した場合、より多くの言語用のライブラリが利用できるようになり、システムと統合する必要がある他のユーザーも利用できるようになります。また、プロトコルを見る目がもっとたくさんあるので、プロトコルが本来のセキュリティと同じくらい安全であることを確認します。
古い投稿ですが、これは役に立つかもしれません：
CAS 3.5は、クライアントとサーバーとしてoAuthをサポートします。参照： https://wiki.jasig.org/display/CASUM/OAuth
私にとって、SSOとOAuthの本当の違いは許可ではなく認証です。明らかにOAuthを実装するサーバーはhas認証（ログインする必要があります）クライアントアプリで発生するOAuthのgoogle、openId、facebookへ）
SSOでは、パワーユーザー/ sysadminが事前に「SSOアプリ」でアプリケーションへの最終ユーザーアクセスを許可しますOAuthでは、最終ユーザーは「OAuthアプリ」で自分の「データ」へのアプリケーションアクセスを許可します
OAuthプロトコルをSSOサーバーの一部として使用できなかった理由がわかりません。フローから許可画面を取り出して、OAuthサーバーに補助データベースから許可を検索させるだけです。