前置き(スルー推奨)

色々なSaaSを使いたいだけ使うだけな状態で個々のSaaSの管理画面以外に可視化されておらず管理不在のカオス状態だった社内ITの管理状況に業を煮やし、せめてID名寄せ程度のアカウント管理くらいしようぜ と各SaaSのAPIを自力で叩いてアレコレし始めて)2年ほど経過。そろそろ~~飽きてきたし~~一通り可視化が出来て管理も回るようになってきたので頭の整理を兼ねてユルユルと書き始めた次第。

TL;DR

バックオフィスで使われがちなSaaSについて、主にAPI経由でのユーザー管理、組織・グループ管理方法周りを下記の視点で緩く書くよ

認証方法
- サーバー間連携を前提とするので認証方法はアクセス毎にユーザーの認可が必要なプロセスを避ける
権限管理方法
SCIM2.0対応してるの?
~~APIやデータの持ち方の癖~~ (これは個別に長くなるのでまたの機会に)

「IDなんもわからん」な人なので、認証・認可方法の名前や分類、意味や使い方あたりで間違いがありましたらコメントや編集リクエストなどでご指摘頂けると幸いです
また対象とするSaaSはAPIに関するドキュメントが公開されているSaaS(契約などが不要でドキュメント単体が誰でも閲覧可能な状態となっているもの)のみとさせて頂きました。
また、比較表へ載せた各SaaS及びそのAPIは、すべて筆者が実際に直接使って検証してみた結果の１ユーザーとしての感想です。

比較表

いきなり本題というかほぼ結論。

SaaS	API ドキュメント	APIのアクセス認証・認可方法
Google Workspace	Directory API	OAuth2.0/JWT
Microsoft 365	Microsoft Graph API	OAuth2.0 Client Credential Grant
Slack / Slack Enterprise Grid	Slack Web API	Slack App Bot Token/User Token + Bearer Token
Git Hub Team	GitHub Rest API	Personal Access Token+BASIC認証
SmartHR	SmartHR API Specification	Bearer Token
Atlassian Jira Software & Confluence	cloud admin REST APIs	Bearer Token with API Key
kickflow	kickflow REST API	Personal Access Token + Bearer 認証
YESOD	従業員情報インポートAPI ほかHELPに記載	API Token + Bearer認証
Cybozu Kintone/Garoon	Cybozu 共通管理API	パスワード認証

SaaS毎の状況

各SaaS毎の認証方法やSCIM2.0への対応等について概要と雑感を記載する。
詳細は各APIのドキュメントを参照されたし。

Google Workspace

Google Workspace 単体のAPIというよりも Google Cloud が用意するAPIのひとつという位置づけとなっており、Google Workspaceのアカウント・ライセンスやグループ、利用アプリの管理や監査ログ確認を行う管理者向けの Google Admin Console に対してアクセスを行うAPI群がGoogle Admin SDKといった形でカテゴライズされている。そのうち基本的なアカウント管理についてはDirectory APIとしてまとめられている。
その為、アクセスの為の設定も他のGoogle Cloud API同様にGoogle Cloud Consoleにて行う。ということは認証・認可の方法も Google Cloud で用意されている OAuth2.0 に則っており、他の Google Cloud で利用できるAPIと同様にIAMでの権限や認証、スコープの設定が必須となる。またAPI利用の為のOAuth2.0フロー上での認可には、当然ながら Google Workspace 上でオーナー権限など各機能が使える権限が必要。
Google Cloud で用意されている API をサーバーサイドで使う際はリフレッシュトークンを利用することで、ユーザー認証を長期間行わなくても良い方法＝ Refresh Token Grant が利用できる。

参考: Google Spreadsheet をサービスアカウントに共有せずにGoogle Spreadsheet APIから読みだす方法

一方で、サービスアカウントを作成し、Google Workspaceで利用するドメイン全体に対する様々な権限利用できるスコープを委任するといった権限委任を行えば(Google Workspace ドメイン全体の権限の委任を行う)、委任の際に行う一度の認可のみで済み、以後はJWTを秘密鍵で署名して受け渡すことにより、再認可なしでAPIアクセスを行うことも出来る。こちらの方が堅牢で王道と思われる。今回紹介している中では最も高機能で最新・安全な認証方法を採用していると言っても過言ではないだろう。
またIdPとなれることからSAMLにも対応しており、IdP Initiated/SP Initiatedいずれも対応している。そしてSCIM2.0にも対応しており、IdPとしてもSPとしても利用できる。

Microsoft 365

こちらも Google Workspace 同様に、Microsoft 365 単体というよりは Microsoft Azure の API のひとつとして Graph API が用意されている。この Gprah APIは実質的には Entra ID (旧:Azure Activce Directory)を始めとて SharePoint や Office Online、Outlook Online、Teams など Microsoft 365 全体に対してアクセスを行うAPIと理解して良い。
認証方法はOAuth2.0では一般的なClient Credential Grantとなる。つまり、Azure に対してOAuth2.0アプリとして登録し、Client ID & Client Secretを取得して行うアレである。
またGoogle Workspace同様に、Microsoft 365 に対する管理系の操作を行う場合は、OAuth2.0利用アプリのアクセス認可はMicrosoft 365を管理する権限を有しているアカウントで行う必要がある。
SAML及びSCIM2.0への対応状況もGoogle Workspaceと同様で、SPとしてもIdPとしても利用できる。まさにGoogle Workspaceと双璧をなすと言っても良いだろう。

Slack

Slack内にAppを作り、そのAppが持つ Bot Token、User Token を利用してAPIアクセスを行う方式。このため、どのようなプランでも、各ワークスペースを利用できるユーザーであれば自由にAppを作り、Bot Token / User Token を発行し、そのTokenをBearer Tokenとして使用する(Bearer認証する)ことで各種APIへアクセスが出来る。
但し、ユーザーを直接招待したり削除する、ユーザーグループを作成する、コネクトに招待する、といった管理用のAPIがまとめられている Admins API は Enterprise Grid のみで利用可能。
言い換えれば、Slack に対して Web API 経由で色々な管理を行いたければ Enterprise Grid が必須となる。
また、Enterprise Grid であれば誰でもAdmin APIが使えるかと言われれば勿論そんなことはなく、Slack Appの登録、Tokenの払い出し、及びAdmin APIへのアクセス認可はワークスペースオーナー以上の権限を持つアカウントが行う必要がある。
SCIM2.0への対応もされており、SPとして利用できる。こちらはSlack Enterprise GridだけではなくBusiness+のライセンスでも利用可能。監査ログやコネクトへのヘッドレスな管理は不要でSCIM2.0によるアカウントのプロビジョニングのみでよければ、こちらを使う手もある。

GitHub

利用方法としては Slack に近く、GitHub用のGitHub Appを作り、そこで設定したClient IDとClient Secretを使用して…というClient Credential Grantが基本となる。
が、Organization に対する管理用のAPI = Organization で Owner 権限を持つアカウントのみが利用できるAPIに関しては別の方法が用意されている。CLIでの操作でも利用されている Personal Access Token を利用したBASIC認証だ。
CLIでのアクセスと同様に、IDにはGitHubユーザー名、パスワードとしてはPersonal Access Tokenを用い、 "ID:PASSWORD" を base64 でエンコードし、それをシグネチャとして Author ヘッダへ付与する~~いつものアレ~~みんな大好きRFC7617だ。
但し単純なBASIC認証とちがって、GitHubアカウントのパスワードそのものを使うわけではなく、個別に生成した Personal Access Tokenを利用する点で、通常のBASIC認証に比べて安心感はある。漏れた可能性を感じるなど不安材料があればPersonal Access TokenをExpireしてしまえば良いし、そう感じる前に定期的に更新する方が望ましい。
尚、SCIM2.0は Enterprise のみ利用可能。Team は基本的に個人アカウントを含めて既存アカウントに対して Organization を管理するのみの機能なので、そもそも本来の「テナントとその中のアカウント」という概念が存在するのは Enterprise のみであり、当然と言えば当然。

SmartHR / Atlassian (Jira Software / Confluence) / kickflow / YESOD

Bearer Token組である。様々な SaaS の Web API における認証方法の中では最大派閥と言って良いだろう。
SaaSの中のアカウントで適切な権限を付与したり、発行するTokenそのものに対して利用できる機能を設定したりするタイプのものが多い。Atlassianが前者でSmartHRが後者。
前者の良いところはアカウントの権限がそのままAPI Tokenの権限となるので権限管理が容易なところ。一方で後者はToken毎に権限を調整できるので細かい権限管理は行いやすい。とはいえTokenの発行そのものが全体の管理者レベルでなければ行えない場合が多い。つまり、APIを利用する際は管理者がAPI Tokenを発行する必要がある。例えば実際の運用例でよくあるケースとして、HRテックSaaSであるSmartHRは利用者も管理者も人事担当者となっているケースが多い。その場合、まず人事の管理担当者にWeb APIやSSOといった機能に対して理解をしてもらった上で、適切なAPI Tokenを発行してTokenに対する権限も必要なもののみを設定してもらうことになる。 (SmartHRの例)
IT担当者が管理していないSaaSについては、恐らくここが最大の山となるだろう。また、SAML及びSCIM2.0の利用に関しても同様で、これらも基本的には管理者のみがSAML/SCIM2.0の設定を行うことができる場合が殆どだ。その場合はAPIの利用と同様にIT管理者がこれらSaaSの管理者となっていない場合は一時的に管理権限を付与してもらう等、交渉が必要となるだろう。

Cybozu (Kintone/Garoon) 共通設定

Kintone、Garoon 各サービスへのアクセスは、それぞれ個別にアプリ単位、アカウント単位でTokenを用意し、Bearer Tokenで利用するといった形式で、SmartHR、Atlassian 組と大差ない。ただし、アカウントや組織、グループの管理を行うCybozu共通管理へのAPIアクセスとなると大幅に話が異なってくる。
Cybozu 共通管理APIを使うためにでサーバーサイドで利用できる認証方法は、なんとパスワード認証(≒実質BASIC認証)のみとなる。しかもCybozuアカウント全体に多大な影響を及ぼすcybozu.com 共通管理者のID&パスワードをそのままbase64エンコードして利用する。もちろんスコープの設定などは一切無い。
よって、サーバー側へクレデンシャル代わりとなるこの情報＝ID&パスワードを設定する際は慎重な扱いが求められる。なにしろそれが盗まれれば、管理者自身のパスワードを変えることもできるし、契約しているアカウントで出来ること全てが可能な全部の権限を持っていかれてしまうからだ。ドメインの変更や契約だって変えられてしまう。IPアドレスの制限ができたり、サイボウズストア管理者と分散管理できるとはいえ、ユーザーアカウントやグループ管理、組織管理というグループウェアの根幹を支える機能に対するアクセスである。もう少し強固で一般的な権限管理の機構が欲しいと思ってしまうのは筆者だけだろうか。
尚、サイボウズの認証基盤はSCIM2.0のユーザープロビジョニングに対応 しており、ユーザーのアカウントの有無に関しては IdP からのプロビジョニングが利用できるという点は記しておく。サイボウズ社としては恐らくこちらを使ってほしいという意図かもしれない。であれば、組織やグループの管理は別の認証方法を持たせたAPIを用意して頂いた方が良い様に思う。
また、SAMLへも対応されてはいるが、IdP Initiated には未対応(SAML認証に関するエラーメッセージ / SLASH_SA02)の様に見受けられる。このため、Chrome利用時はSAMLが設定されているとメニューにアイコンが表示されるものの、そこからKintoneの起動は出来ない。

雑感

さすがに IdP となれる Google Workspace と Microsoft 365 に関してはSCIM2.0への対応はもちろん、それ以外の機能に関する管理方法がすべてAPIベースで整備されており、完全にヘッドレスな運用を行うこともできる。そして自社で持っているPaaS/IaaSと同様のアクセスを提供しており、それはユーザー操作を行うAPIでも他APIと同様の方法：JWTやClient Credential Grantを使ってアクセス、及びアクセス管理ができることを意味している。
それ以外のSaaSではなんらかのTokenを発行させるBearer認証が目立つ。この場合、最初から、或いはなんらかの追加オプションを選択すれば管理機能へもほぼフルアクセスできる。つまり限りなくヘッドレスな運用が出来るようになっている。複数のSaaSを利用する機会が増えてきた昨今、個々の管理UIを開かなくとも必要な機能へのアクセスに限定して管理を集中させるようなヘッドレスな運用が目指せるSaaSが増えてきたことは喜ばしい。いや、むしろ、最早SaaSはAPIが用意されていることが前提であるといっても過言ではない。SAMLによるSSOやSCIM2.0によるユーザープロビジョニングは最低限で、更に管理機能やそれ以外のものもヘッドレス運用が出来ることがSaaSとしての前提条件。つまりインターフェースとしてはAPIとUIが違うというだけで、機能としては同じことが出来る、という仕様が望まれる。ただし、ここは実際に利用するユーザー側がUI利用が多いのかAPI利用が多いのかで異なってくるので、マーケットインとプロダクトアウトでAPIに対するアプローチが大きく変わってくる点かもしれない。ただひとついえることは、ライトコード・ノーコードツールからのWeb APIアクセスが容易となった今、APIアクセスで出来ないことがある点は間違いなく選択肢から外れる要因と成り得てくるだろう。
一利用者としては、APIとUIが同じ前提となっているSaaSのみを選んで使っていきたい。