OAuth とは何か — パスワードを渡さず、範囲と期限を決めて許可する仕組み
外部のサービスに自社のシステムを連携させるとき、素朴に考えるとそのサービスに ID とパスワードを教えることになります。これは危険です。渡した相手は何でもできてしまうからです。
この問題を解くために作られたのが OAuth 2.0 です。RFC 6749 という標準文書で定められています。OAuth の説明はこのページにまとめてあり、ほかの調査記事からはここを参照しています。
パスワードを渡さない、という発想
OAuth は、パスワードを渡さずに、限定的な権限だけを渡す仕組みです。会社の建物に例えると、受付が発行する「入館証」です。
| OAuth の言葉 | 建物に例えると |
|---|---|
| resource owner | 建物の持ち主（＝あなた） |
| client | 作業に入る業者 |
| アクセストークン | 入館証 |
| scope | 入れる範囲（どのフロアのどの部屋か） |
| 有効期限 | いつまで使えるか |
| 取り消し | 受付でその入館証だけを失効（ほかの入館証は無事） |
「合鍵」に例えられることもありますが、合鍵は元の鍵の複製なので、この仕組みの説明としては逆です。合鍵は元の鍵と同じ扉が全部開き、期限がなく、無効にするには錠ごと替えるしかありません。OAuth はその 3 つとも反対で、範囲が絞られ、期限があり、それだけを取り消せます。
規格の言葉では、許可を出す主体を resource owner、それが人間である場合を end-user と呼びます（RFC 6749）。「利用者」と書きます。なお resource owner は アクセス許可の主体を表す規格上の用語 であって、法律上のデータ所有権を定める言葉ではありません（ここは区別しておきます）。
「いつまで」と「取り消し」— 期限は短くても、取り消すまで続く
アクセストークンには 3 つの性質があります。連携ツールに渡す前に、それぞれをどこで確かめるかまで含めて見ておくと、渡したあとに慌てません。
| 性質 | 意味 | 確かめる場所 |
|---|---|---|
| 範囲（scope） | 何を読めて、何を書き換えられるか | 連携を許可する画面に出る一覧。各システムの認証欄（RenkeiMap の「認証」） |
| 期限 | アクセストークン自体は短い（1 時間などの例が多い）。ただし多くの実装ではリフレッシュトークンで自動更新され続ける | 提供元の API 文書の「トークンの有効期限」 |
| 取り消し | そのトークンだけを失効できる。規格側にもトークン失効の標準 RFC 7009 がある | 各サービスの「連携アプリ」管理画面 |
期限について 1 つ正確に書いておきます。アクセストークン自体の期限は短くても、リフレッシュトークンで更新され続けるので、利用者の体感としては「期限が来たら切れる」のではなく「取り消すまで続く」ことになります。だから 取り消す場所 を先に確認しておく意味があります。
用語について 1 つ補足します。厳密には、OAuth 2.0 は認可（何を許可するか）の枠組みであって、認証（本人確認そのもの）は OpenID Connect などが担う別の話です。各社の公式資料は「認証方式」という見出しの下に OAuth を並べていることが多いので、この調査記録でもそれに合わせて認証方式の 1 つとして扱っています。
調査記録で確かめる
例として経理・会計のカテゴリで見ます。認証の方式と、選べる手段の 2 列です。
比較項目:
| システム | 業務ワークフロー円滑度 |
|---|---|
| API の認証方式 | |
| バクラク | ○API認証情報発行第三者認証ID／認証キー 会社が発行する API 認証情報を使う ベンダー公表 API を使う相手を認証するための情報は、会社の側から発行される。その情報は自分の費用と責任で厳重に管理するものとされ、第三者に使わせたり貸したり譲ったりすることはできない。ただし、社内やその業務関係者に個別サービスを使わせる目的の範囲でなら、使わせてよいとしている。発行された認証情報を使った利用は、本人による利用とみなされる。方式の名前（OAuth なのか鍵ひとつなのか）は規約には書かれていない。 |
| board | ○APIキーAPIトークン 2方式の併用が必須: ①APIキー（x-api-key ヘッダー・アカウントで1つ発行）＋②APIトークン（Authorization: Bearer・複数発行可でトークンごとに利用可能エンドポイントを指定可）。OAuthなし ベンダー公表board APIドキュメン…()ほか 1 件
採取元: board APIドキュメント（認証・認可）・board APIドキュメント（APIキー）・board APIドキュメント（APIトークン）
調査日 |
| e-Tax | ○APIキーメールでの発行申請利用規約への同意OAuth なし API はAPIキー（API認証情報）方式で、専用アドレスへのメールでの発行申請と利用規約への同意が要る。セルフサービスで即時発行される OAuth なしの方式。利用者側の認証はマイナンバーカード等の電子証明書と利用者識別番号。 ベンダー公表国税電子申告・納税システムA…()
国税電子申告・納税システムAPI（ご利用に当たって） ベンダー公表 ℹ️発行申請書・変更届出書は Word 形式で配布され、メール件名の書式まで指定されている。開発者ポータルやコンソールで自動発行する仕組みは公開されていない。
採取元: API認証情報（APIキー）・同上・同上（利用規約）
調査日 |
| eLTAX / PCdesk | ○利用者ID暗証番号マイナンバーカード電子証明書 利用者IDと暗証番号、またはマイナンバーカードで本人確認する。送信する申告データには電子証明書による電子署名を付ける。マイナンバーカードでのログインは利用申請が要る。 |
| freee会計 | ◎OAuthスコープ OAuth2（authorization_code）。 |
| freee申告 | ログイン試行回数の制限リスクベース認証 サービスへのログインは freee アカウント。ログイン試行回数の制限に加え、リスクベース認証（普段と異なる環境からのログインはアカウントロック）を実施。 |
| invox | ◎OAuth2.0アクセストークンクライアントID OAuth 2.0。認可を経て発行したアクセストークンで呼ぶ。クライアント ID はベンダーが発行する（自己登録ではない）。 |
| ジョブカン会計 | ○アクセストークン Bearer トークン認証 編集部確認 仕様書が宣言する方式は Bearer トークンのみ（HTTP Authorization ヘッダー）。加えて会社を特定する Jbc-Api-Client-Id、年度データを特定する X-Api-Data-Key といった独自ヘッダーが必須。 編集部確認ジョブカン会計API 仕様書…()
ジョブカン会計API 仕様書（認証） 編集部確認 ℹ️保存済みドキュメントに埋め込まれた OpenAPI 定義の securitySchemes は Bearer（type: http, scheme: bearer）1件のみ（編集部が機械的に確認）。申請フォームには「OAuth 2.0 認証による自社サービス・アプリとの連携」という選択肢と Callback URL の入力欄があり、OAuth を使う経路は個別申請の中で案内される模様だが、公開仕様書には OAuth の定義は無い。
採取元: ジョブカン会計API 仕様書（認証）
調査日 |
| Misoca | ◎OAuth2readwrite OAuth2.0。スコープは read と write の 2 つ（write があれば読み込みもできる）。トークンの有効期間は 1 日で、必要に応じてリフレッシュする。 |
| マネーフォワード クラウド会計 | ◎OAuthAPIキー |
| マネーフォワード クラウド経費 | ◎OAuthアクセストークン OAuth 2.0（Authorization Code Grant）。securityDefinitions は `mf_expense_oauth`（authorizationUrl /oauth/authorize、tokenUrl /oauth/token）。 ／ スコープ6種：office_setting:write（事業者の設定から事業者の従業員の設定まで管理）／user_setting:write（ユーザー自身の設定）／transaction:write（明細の読み書き）／report:write（申請の読み書き）／account:write（連携サービスの管理）／public_resource:read（公開リソースの読み込み）。 ベンダー公表Swagger 定義（sec…()ほか 1 件
moneyforward/expense-api-doc README（2026-08-02 取得） 編集部確認 ℹ️アクセストークンには有効期限があり、リフレッシュトークンによる更新、即時無効化（revoke）、有効性確認のエンドポイントが用意されている。
採取元: moneyforward/expense-api-doc README・Swagger 定義（securityDefinitions.mf_expense_oauth.scopes）・moneyforward/expense-api-doc README（トークン操作）
調査日 |
| マネーフォワード クラウド請求書 | ◎OAuthAPIキー 認可は OAuth 2.0。マネーフォワード クラウド共通では OAuth 2.0 による認可と API キーによる認証の 2 方式がある。 |
| 楽楽精算 | ―IPアドレス制限SSLクライアント認証 API 自体の認証方式（トークン／OAuth 等）は公開されていない。公開されているのはアクセス制限側の話で、「IPアドレス制限オプション」「SSLクライアント認証オプション」を契約している場合、API 連携の実行プログラムが到達できるよう、前者はアクセス元サーバーの IP を登録、後者はアクセス元サーバーに SSL クライアント証明書をインストールする必要があると明記されている。 編集部まとめ出典()
|
| TKC FX2クラウド | ― つなぐときにどうやって身元を確かめるのかを書いた記載は、開いた範囲には無い。銀行やクレジットカードのデータを受け取る機能については、インターネットバンキングの契約や明細照会サービスの登録が要ること、提携先の利用規約への同意が要ることが案内されているが、これは相手側の手続きの話で、つなぎ方の認証方式ではない。 ベンダー公表会計ソフト FXクラウドシリ…()ほか 1 件
|
| TOKIUM | ◎SAMLメールアドレス権限 メールアドレスとパスワード、SAML ベンダー公表 画面にログインする方法として、メールアドレスとパスワードによる認証と SAML による認証が提供されている。SAML があるということは、会社の ID 基盤に寄せた運用ができる。管理者権限と承認者権限は利用ユーザーごとに設定でき、管理者によるユーザーの追加と凍結、利用者自身によるパスワードの再設定の機能がある。管理者権限を持つユーザーは、申込書に書かれたメールアドレス宛に発行される。なお、これは画面にログインするための話で、API を呼ぶときの認証方式は公開されていない。 ベンダー公表セキュリティホワイトペーパー…()
採取元: セキュリティホワイトペーパー（8.2 特権的アクセス権）・セキュリティホワイトペーパー（5.18 アクセス権）・セキュリティホワイトペーパー（5.16）
調査日 |
| 弥生（会計/青色申告 オンライン/Next） | ― 第三者が叩ける公開 Web API が無いため認証方式も無い 調査日 |
◎ 条件なしで当てはまる ○ 条件つき・一部 △ 限定・要申請・無いと明記 × 当てはまらないと明記 ？ 編集部がまだ確認していません ― 提供元が公開していない（編集部が調べた） — 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。
材料の調査日（最新）: 2026-09-03