B2B SaaSにおける認可サーバー開発で意識したこと

こんにちは！バクラク事業部の@ysakura_です。
先日、バクラクシリーズで共通的に利用できる OAuth 2.0 の認可サーバーを開発しました。今回は、認可サーバーを開発する中で直面したB2B特有に意識すべき点を紹介します。
会社・従業員という概念が登場するため、個人向けの場合と比べて考慮する要素が増えます。

連携担当の権限チェック

お客様のデータを他社のサービスに連携するので、想定外の連携を発生させない事が重要です。その為、連携担当者が管理者権限を有しているかのチェックを入れています。
こういった機構が無いと、一般権限の従業員が 攻撃者のサービス に誤ってデータ連携をする事が起こり得ます。また、従業員個人のアプリに会社の情報を引き抜く事も原理的には可能です。(あまり想定したくはありませんが)
上場企業やIPO準備企業では、内部統制として求められる内容かと思います。

毎回ログインを要求する

B2BのSaaSでは、同じサービスで複数のアカウントを持つ方が一定数います。
例えば、親会社の経理など業務をする上で複数のアカウントが必要な方が該当します。
※ アカウントを分けないケースもあります(後述)
他にも、個人用と会社用のアカウントがあるケースも存在します。(例. 副業でSaaSを利用)
連携したいアカウントとは別のアカウントで誤って連携する事が起こらない様に、毎回ログインを要求しています。

従業員の異動・退職を想定する

B2Bでは、従業員が異動・退職をしアカウントが停止されても会社としてSaaSの利用は続いている、という事が通常起こります。この異動・退職した従業員が連携を行っていた場合に、その後の連携をどうするか考える必要があります。
これは判断が分かれる所で、連携を強制解除する / 連携をそのまま続ける / アラートを出す / 連携専用のアカウントを作る、などサービスの状況やユーザー層によって様々かと思います。

API連携の認証情報として何が必要か考える

B2Bではアカウントに紐づく認証情報として、主に下記の3つがあります。
1アカウントが複数の会社に所属する事もある為、こういった構造になります。

会社(テナント)
- 例) 株式会社LayerX
個人(ユーザー、アカウント)
- 例) sakuraさん
従業員(テナントユーザー)
- (会社、個人)の組でユニーク
- 例) 同一の個人だが会社が異なるので別の従業員として扱われるケース
  - 株式会社LayerXのsakuraさん
  - 株式会社Bのsakuraさん

これらの情報の一部もしくは全てをアクセストークンに紐付ける事が多いです。

※ 今回のケースでは、同一のアカウントで複数の会社に所属する状況を想定しています。
例えば、親会社の経理 / 税理士 / 監査法人などの方が該当します。

各ケース毎の例

どの認証情報を紐付けるか考えるにあたって、各ケース毎のAPI連携の例を書いてみます。

会社単位のAPI連携
- ユーザー情報が不要な連携
- 例
  - 会計ソフトが請求書サービスの明細を取り込む
従業員単位のAPI連携
- (会社、ユーザー)の情報が必要な連携
- 例
  - Slack で従業員が請求書サービスの承認を出来る
個人単位のAPI連携
- ユーザーの情報だけが必要な連携
- 遭遇した事はないので、想定するユースケースになります
  - 個人が所属する全ての会社に対して、1つの連携で作業をしたい
  - 例
    - 親会社の人が情報を集約したい
      - 連結会計など

どう考えるか

API連携のユースケースを整理し、どの情報を紐付ける必要があるかを検討するのが良いと思います。全ての情報をアクセストークンに紐づけておくのも1つの手です。
懸念事項として、後から追加で認証情報が欲しくなっても過去のアクセストークンでは取得出来ない、という事も起こり得ます。(例. 従業員単位のAPI連携を追加で開発したい)
※ 再連携をClientに依頼すれば対処可能です