SAML2を介したSSOを許可するサービスがあります。 SAML2を使用する場合、認証プロセス全体をIDプロバイダーに委任します。
一部のモバイルアプリケーションをサポートするために、OAuthを追加することを検討しています。ユーザーが常にログインする必要はありません。)
スタック全体を制御しているため、独自のユーザー名/パスワード認証を使用している場合、どのように連携するかは明らかです。
OAuthはSAML2 SSOとどのように相互作用しますか?たとえば、IDプロバイダーがユーザーを削除した場合、OAuth Grantsを無効にするために何をすべきですか?他に何が問題ですか(うまくいけば標準的なソリューション)がありますか?
私が知っているこの組み合わせの唯一の実装はSalesforceです。あなたがやろうとしていることは複雑なセットアップです-両方のプロトコルは単純ではなく、あなたが述べたようなそれらの相互作用に問題があります。
このドキュメントをご覧ください(外部からのSFの実装の様子)- https://wiki.developerforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth
このドラフトを確認してください(私は個人的に掘り下げていませんでしたが、具体的にはあなたのケースに対処しています https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-16
SAMLとOAuth 2.0フレームワークをブリッジすることはよく理解されている問題です。IETF仕様の次のスタックは標準的なソリューションを提供します:
コア OAuth 2.0仕様 (RFC 6749)とその トークンエンドポイント定義 を見ると、これは基本的にOAuthサーバーエンドポイント" grant "-クライアントアプリに access token の発行を許可するのに適切と見なされる何かの制限のない概念と引き換えにアクセストークンを返します。典型的なOAuthシナリオこれは 承認コード ですユーザーが以前に認証され、同意を得ていることを示しています。
draft-ietf-oauth-assertions-16 と呼ばれるIETF仕様には、コアRFC 6749標準に基づいてさらに付与されたものもアサーション(署名付きの証明)であり、そのために必要なトークン要求パラメーター。
最後に、 draft-ietf-oauth-saml2-bearer-2 があり、このアサーションをSAML 2.0ベアラーアサーションにする方法を指定します。
SAMLアサーションをOAuth 2.0アクセストークンに変換するためのこの標準メカニズムは、基本的に2つのフレームワークをブリッジするために必要なすべてです。
ユーザーの削除が承認システムに適切に反映されるようにするには、2つの方法を組み合わせることができます。
OAuthはauthorizationフレームワークです。 RFC6749 から
OAuth 2.0承認フレームワークにより、サードパーティアプリケーションはHTTPサービスへの制限付きアクセスを取得できます
そして、SAMLは認証フレームワークです。 SAMLアサーションには認証情報が含まれています。通常、SAMLはSSOに使用されますが、SAML標準にはAuthorization decision assertion
。これは、いくつかの承認情報を運ぶために使用できます。
SAMLドキュメント here から詳細情報を取得できます。
質問にはシステムの実装に関する詳細は記載されていませんが、目的が異なる2つのまったく異なる標準をマージするのではなく、SAML 2.0の認証機能を使用することをお勧めします