OAuth2.0のどのフローを選んだら良いかをお聞きしたいです。

背景

一企業の閉じたLANで、サービスAを提供しています。
サービスAはSPA＋バックエンドのシステムです。

システム自体にはログイン機能があり、ID/PWを基に認証して、Tokenを返し、
APIリクエスト時にBearer Tokenを投げるようにしております。

また、サービスAは1つの部署(部署A)が運用しており、
内部のリソース自体もエンドユーザーというよりその部署が所有し、
責任を持っております。

この度、別部署(部署B)においてサービスBを提供することになり、
サービスAと連携する(サービスAのAPIを使用する)ことになりました。
サービスBも、SPA＋バックエンドの構成です。

質問内容

上記条件で、サービスBのエンドユーザーがサービスAを使用する場合、
OAuth2.0のどのフローを使用して、認可すればよいでしょうか。

疑問の中心点としては、サービスAのリソースを所有しているが
ユーザーではなく部署Aであるので、
認可エンドポイントをどのように行うかということです。

できるだけOAuthを試したいということもあり、
必要ないという場合でも、少しでもFITするフローがあれば試してみたいと思っております。

ご不明な点があれば、教えてください。
よろしくお願いします。

yoorwm

2020/04/08 01:39

それはつまり、ご自身でOAuthのサービスプロバイダを実装する、という事ですか？

honesome

2020/04/08 02:18 編集

そうだと認識しています。 Firebase等は使えないので、Spring Security、OpenAMまたはKeycloak等を使用することを想定しています。

行動規範の内容に同意します

回答1件

回答

OAuth2.0のどのフローを使用して、認可すればよいでしょうか。

ここでおっしゃるフローとは、以下の4つを指しているでしょうか。

認可コード
インプリシット
リソースオーナー・パスワード・クレデンシャルズ
クライアント・クレデンシャルズ

これらについての質問であれば、1番の「認可コード」を利用すべきです。
（加えてPKCEも使うべきと考えられます）

認可コード以外のフローを利用すべきでない理由は以下のとおりです。

インプリシット
SPAからトークン要求する場合を想定した仕様ですが現在は非推奨となっています。
代わりに認可コード＋PKCEの利用が推奨されています。

リソースオーナー・パスワード・クレデンシャルズ
クライアントにユーザーの認証情報（ID/パスワード）が渡ってしまいます。
今回のケースでいうと、サービスBがサービスAの認証情報を取得できてしまうということです。
（別にサービスBが認証情報を知ってもいいのであれば、リソースオーナー・パスワード・クレデンシャルズを利用してもいいと思います）

クライアント・クレデンシャルズ
クライアントの認証のみ行います。
りユーザー認証が行われないので、エンドユーザーが複数いるようなサービスでは使いません。