開発中のさまざまなAPIに認証を追加することを検討しています。このソリューションは現在のところ完全に流動的ですが、基本的な前提は、顧客がインターフェイスするAPIレイヤーが1つあり、その背後にこの最初のレイヤーが委任するAPIがいくつかあることです。
提案された図の一部には、ユーザーが一度認証し、生成されたトークンを使用して利用可能なすべてのリソースにアクセスできるようにするシングルサインオンサーバーが含まれています。
これを読めば読むほど、oAuthがこのモデルにどのように適合するかについての私の理解は奇妙になります。私が見ることができることから、oAuthは単にサポートしますクライアントアプリケーションの認証。ユーザーがいくつかの権限を付与したい。
私たちの目的は、シンプルなログイン機能をシングルサインオン方式で作成することです。 oAuthはこれに適していますか、それとも複数のアプリケーションの単一サーバーに認証の信頼を委任するためのより適切なソリューションがありますか?
OAuthは認証プロトコルであり、認証プロトコルではありません。
プロセスのある時点で、ユーザーは承認サーバーに対して認証を行い、アプリの保護されたリソースへのアクセスを承認できることを証明する必要があります。
保護されたリソースはユーザーを一意に識別するユーザーに関する情報である可能性があるため、認証サービスをoauth2の上に構築できますが、そのためには、OAuthとその理由を十分に理解する必要があります。箱から出してすぐに認証するのには適していません。
幸いなことに、OpenIDConnectのスタッフはすでにあなたのために大変な仕事をしてくれました。
OAuthあなたが実際にOpenIDを意味していると仮定すると、そうだと思います。SSOスキームに使用することは非常に良い考えです。それはうまく機能し、十分に証明されており、多くの拡張性があります。
また、ほとんどすべてのものに統合するのは非常に簡単です。