FileMaker OData API を外部ドメイン(SPA)から OAuth 認証で利用する際の認証フローの調査と検証
更新履歴
2026年01月23日 追記
本記事の検証結果を元に、Angular (SPA) を使用した実装デモを作成しました。
SPA(Angular)から FileMaker Data API を安全に使うための OAuth 認証とセキュリティ構成
目次
- 1. はじめに
- 2. OAuth プロバイダ情報の取得
- 3. 認証用URLとリクエストIDの取得
- 4. 認証フローと Identifier の取得
- 5. OData API の実行と CORS の壁
- 6. 技術的な考察と課題
- 7. まとめ
この記事のポイント
- OAuth プロバイダを使用した OData API 接続の実証
- 外部ドメイン(SPA)を経由して FileMaker Server へ認証情報を引き渡すリダイレクトフロー
- 外部ドメイン(SPA)へのリダイレクトバックが成功することを確認
- ブラウザからの直接アクセス時に発生する CORS エラーと対策
1. はじめに
Angular、React、Vue.js などのモダンなフロントエンドフレームワーク(SPA)と FileMaker を組み合わせたい場合、FileMaker OData API は有力な選択肢です。特にセキュリティ要件の高い環境では「OAuth アイデンティティプロバイダ(IdP)を利用した認証」が必須となるケースがあります。
本記事では、外部ドメインで運用される SPA からの接続を想定し、検証用ドメイン https://redirect.frudens.com/ を使用して、認証から API 実行までのフローを検証します。
OAuth アイデンティティプロバイダを使用したデータベースセッションへのログイン
OAuth アイデンティティプロバイダを使用して共有データベースにログインするには、データベースを参照する API エンドポイントを使用します。
ヘッダの X-FM-Data-OAuth-Request-Id 文字列および X-FM-Data-OAuth-Identifier 文字列を使用して共有データベースへのアクセスを認証します。
認証されると、API エンドポイントから対応する応答を受け取ります。
公式ドキュメントを読み解きながら、実際に接続できるか検証を行います。
認証フローの全体像
検証の結果判明した、正常な認証フローをシーケンス図に整理しました。SPA が Google からのコールバックを一度受け取り、即座に FileMaker Server(FMS)へ転送する流れになります。
(redirect.frudens.com) participant FMS as FileMaker Server
(demo-ig5aiy.frudens.com) participant Google as OAuthプロバイダ
(Google) note over SPA, FMS: Step 1 & 2 プロバイダ情報・認証URL取得 SPA->>FMS: GET /oauth/getoauthurl(Return-URL指定) FMS-->>SPA: 認証用URL + X-FMS-Request-ID note over User, Google: Step 3 認証プロセス SPA->>User: 認証用URLへリダイレクト User->>Google: Googleログイン & 許可 Google-->>User: リダイレクト(認証コード) note right of User: Google -> SPA(/oauth/redirect) note over SPA, FMS: Step 4 FMSへの転送とIdentifier発行 User->>FMS: リダイレクト(認証コード + state) note right of User: SPA -> FMS (/oauth/redirect) note right of FMS: FMS内部でセッション生成
Identifier 発行 FMS-->>User: 最終リダイレクト(Identifier付与) note right of User: FMS -> SPA(/my/callback) note over SPA, FMS: Step 5 OData API 実行 User->>SPA: SPA画面表示(パラメータ取得) SPA->>FMS: GET /fmi/odata/v4/... note right of SPA: 【課題】ブラウザから直接叩くと
CORSエラーになる
2. OAuth プロバイダ情報の取得
まず、FileMaker Server で有効になっている OAuth プロバイダの情報を取得します。今回は事前に Google をプロバイダとして登録済みである環境を前提とします。
#!/bin/bash
HOST="demo-ig5aiy.frudens.com"
OUTPUT="response_provider_info.json"
curl -X GET "https://${HOST}/fmws/oauthproviderinfo" | tee "${OUTPUT}"
レスポンスとして、プロバイダ設定(Google)の情報が返ってきます。ここで ProviderID や AuthType などのパラメータを確認します。
{
"data": {
"Provider": [
{
"AdditionalQueryParams": "",
"AuthCodeEndpoint": "accounts.google.com/o/oauth2/auth",
"AuthType": 2,
"ClientID": "368922767362-no0be7vevtdopfh5mm51p5cnsvo51sk5.apps.googleusercontent.com",
"Icon": "http://filemaker.parseapp.com/google.png",
"Name": "Google",
"OIDCEnabled": true,
"ProviderEnabled": true,
"ProviderID": 3,
"Response Type": "code",
"Scope": "profile openid email"
}
]
},
"result": 0
}
3. 認証用URLとリクエストIDの取得
次に、実際の認証プロセスを開始するためのURLを生成します。ここで重要なのは、X-FMS-Return-URL に FileMaker Server とは異なる外部ドメイン(SPA の URL) を指定している点と、レスポンスヘッダに含まれる x-fms-request-id です。これが後のAPIリクエスト時のキーとなります。
#!/bin/bash
HOST="demo-ig5aiy.frudens.com"
REDIRECT_HOST="redirect.frudens.com" # SPAのドメイン
TRACKING_ID="123"
PROVIDER="Google"
HEADER_FILE="response_auth_headers.txt"
BODY_FILE="response_auth_url.txt"
# Return-URL に外部ドメインを指定
curl -X GET "https://${HOST}/oauth/getoauthurl?trackingID=${TRACKING_ID}&provider=${PROVIDER}&address=${REDIRECT_HOST}&X-FMS-OAuth-AuthType=2" \
--dump-header "${HEADER_FILE}" \
--header "X-FMS-Application-Type: 9" \
--header "X-FMS-Application-Version: 15" \
--header "X-FMS-Return-URL: https://${REDIRECT_HOST}/my/callback" | tee "${BODY_FILE}"
実行すると、Google の認証画面へ遷移するための長い URL が取得されます。
https://accounts.google.com/o/oauth2/auth?client_id=368922767362-no0be7vevtdopfh5mm51p5cnsvo51sk5.apps.googleusercontent.com&redirect_uri=https://redirect.frudens.com/oauth/redirect&scope=profile openid email&response_type=code&state=WC1GTVMtUmVxdWVzdC1JRD0xMTRERDk5RTA3NzcyQjBCQjRBQjM0QUI5MkYwRUIwOA==.WC1GTVMtT0FVVEgtUHJvdmlkZXI9R29vZ2xl.WC1GTVMtT0F1dGgtQXV0aFR5cGU9Mg==.WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vcmVkaXJlY3QuZnJ1ZGVucy5jb20vb2F1dGgvcmVkaXJlY3Q=.
同時に出力されたヘッダファイルを確認し、x-fms-request-id を控えます。
HTTP/2 200
server: nginx
date: Wed, 24 Dec 2025 00:08:26 GMT
content-type: text/html; charset=utf-8
content-length: 458
accept-ranges: bytes
x-fms-request-id: 114DD99E07772B0BB4AB34AB92F0EB08
x-fms-result: 0
strict-transport-security: max-age=31536000; includeSubDomains
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
access-control-allow-origin: ubuntu-gk9
access-control-allow-credentials: True
access-control-allow-headers: Content-Type,Authorization
この 114DD99E07772B0BB4AB34AB92F0EB08 が、後の API 実行時にヘッダへ付与する X-FM-Data-OAuth-Request-Id となります。
補足 state パラメータの構造
取得された認証用 URL に含まれる state パラメータを解析すると、「ドット(.)」で区切られた複数の Base64 文字列で構成されており、デコードすると FileMaker Server が内部で管理するセッション情報が埋め込まれていることが分かります。
| # | Base64文字列 | デコードされた値 |
|---|---|---|
| 1 | WC1GTVMtUmVxdWVzdC1JRD0xMTRERDk5RTA3NzcyQjBCQjRBQjM0QUI5MkYwRUIwOA== | X-FMS-Request-ID=114DD99E07772B0BB4AB34AB92F0EB08 |
| 2 | WC1GTVMtT0FVVEgtUHJvdmlkZXI9R29vZ2xl | X-FMS-OAUTH-Provider=Google |
| 3 | WC1GTVMtT0F1dGgtQXV0aFR5cGU9Mg== | X-FMS-OAuth-AuthType=2 |
| 4 | WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vcmVkaXJlY3QuZnJ1ZGVucy5jb20vb2F1dGgvcmVkaXJlY3Q= | X-FMS-Redirect-URL=https://redirect.frudens.com/oauth/redirect |
ヘッダで取得した x-fms-request-id が state 内にも格納され、認証フロー全体を通して引き継がれている様子が見て取れます。
4. 認証フローと Identifier の取得
取得した認証 URL にブラウザでアクセスし、Google アカウントでログインします。
リダイレクトの挙動
認証成功後のリダイレクトチェーンは以下のようになります。
認証とリダイレクトの流れ
-
Google -> SPA
Google での認証後、SPA(/oauth/redirect)へ戻ります。 -
SPA -> FMS
SPA は受け取った認証コードを持って、FileMaker Server(/oauth/redirect)へリダイレクト(転送)します。 -
トークン発行とIdentifier生成
FMS 内部で認証コードからトークンとセッション(Identifier)を生成します。 -
FMS -> SPA(最終リダイレクト)
Step 3 で指定したX-FMS-Return-URL(https://redirect.frudens.com/my/callback)へリダイレクトされます。 -
パラメータの受け取り
リダイレクト時の URL パラメータにidentifierが付与されます。
Step 4-1. Google から SPA へ
Google でのログイン完了後、SPA(/oauth/redirect)にリダイレクトされます。この際、URL パラメータに code や state が含まれています。
https://redirect.frudens.com/oauth/redirect?state=WC1GTVMtUmVxdWVzdC1JRD0xMTRERDk5RTA3NzcyQjBCQjRBQjM0QUI5MkYwRUIwOA%3D%3D.WC1GTVMtT0FVVEgtUHJvdmlkZXI9R29vZ2xl.WC1GTVMtT0F1dGgtQXV0aFR5cGU9Mg%3D%3D.WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vcmVkaXJlY3QuZnJ1ZGVucy5jb20vb2F1dGgvcmVkaXJlY3Q%3D.&code=4%2F0ATX87lNcMAJUdf4JjaNsrfABBUWf3xRCnhXttQjHfEBWPl5mmL-xsQ1XsT04H39j851PCg&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=0&hd=frudens.com&prompt=consent
Step 4-2. SPA から FMS へ
SPA は、このルート(/oauth/redirect)がロードされた際に、パラメータをそのまま引き継いで FileMaker Server(/oauth/redirect)へリダイレクト(転送)する必要があります。
以下は、SPA 側で実行するリダイレクト処理のイメージです(実際には現在のURLパラメータを動的に取得して構築します)。
function redirect() {
// const spaUrl = 'https://redirect.frudens.com/oauth/redirect?state=WC1GTVMtUmVxdWVzdC1JRD0xMTRERDk5RTA3NzcyQjBCQjRBQjM0QUI5MkYwRUIwOA%3D%3D.WC1GTVMtT0FVVEgtUHJvdmlkZXI9R29vZ2xl.WC1GTVMtT0F1dGgtQXV0aFR5cGU9Mg%3D%3D.WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vcmVkaXJlY3QuZnJ1ZGVucy5jb20vb2F1dGgvcmVkaXJlY3Q%3D.&code=4%2F0ATX87lNcMAJUdf4JjaNsrfABBUWf3xRCnhXttQjHfEBWPl5mmL-xsQ1XsT04H39j851PCg&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=0&hd=frudens.com&prompt=consent';
// const fmsRedirectUrl = 'https://demo-ig5aiy.frudens.com/oauth/redirect?state=WC1GTVMtUmVxdWVzdC1JRD0xMTRERDk5RTA3NzcyQjBCQjRBQjM0QUI5MkYwRUIwOA%3D%3D.WC1GTVMtT0FVVEgtUHJvdmlkZXI9R29vZ2xl.WC1GTVMtT0F1dGgtQXV0aFR5cGU9Mg%3D%3D.WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vcmVkaXJlY3QuZnJ1ZGVucy5jb20vb2F1dGgvcmVkaXJlY3Q%3D.&code=4%2F0ATX87lNcMAJUdf4JjaNsrfABBUWf3xRCnhXttQjHfEBWPl5mmL-xsQ1XsT04H39j851PCg&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid&authuser=0&hd=frudens.com&prompt=consent';
// 実際には window.location.search からパラメータを取得します
const params = new URLSearchParams(window.location.search);
const state = params.get('state');
const code = params.get('code');
// ...その他のパラメータ処理
// FileMaker Server のリダイレクト用エンドポイントを構築
const fmsRedirectUrl = `https://demo-ig5aiy.frudens.com/oauth/redirect?state=${state}&code=${code}&...`;
// FMS へリダイレクト
window.location.href = fmsRedirectUrl;
}
Step 4-3. FileMaker Server での処理とコールバック
SPA からリダイレクトされると、FileMaker Server は認証コードを検証し、トークン発行と Identifier 生成を行います。
Step 4-4. FMS から SPA へ
処理が完了すると、FMS は最初に指定した Return-URL(SPA の /my/callback)へリダイレクトします。この際、URL パラメータに重要な identifier が付与されます。
この identifier の値(3E563425F1AE77B11636F59CB344D64C)が、API ヘッダの X-FM-Data-OAuth-Identifier になります。
これで OData API へのリクエストに必要な「2つの鍵」が揃いました。
- X-FM-Data-OAuth-Request-Id(Step 3でヘッダから取得)
- X-FM-Data-OAuth-Identifier(Step 4でURLから取得)
5. OData API の実行と CORS の壁
公式ドキュメントに従い、取得した2つのキーを使用して、テーブル一覧を取得するリクエストを送信してみます。
データベース内のテーブルおよびテーブルオカレンスの一覧の取得
データベースからテーブルの一覧を取得するには、HTTP GET メソッドを使用して URL にデータベース名を追加します。
以下のスクリプトで実行します。
#!/bin/bash
HOST="demo-ig5aiy.frudens.com"
OUTPUT="response_table_list.json"
DATABASE_NAME="blank01"
# 取得した値をセット
REQUEST_ID="114DD99E07772B0BB4AB34AB92F0EB08"
IDENTIFIER="3E563425F1AE77B11636F59CB344D64C"
curl -X GET "https://${HOST}/fmi/odata/v4/${DATABASE_NAME}" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--header "X-FM-Data-OAuth-Request-Id: ${REQUEST_ID}" \
--header "X-FM-Data-OAuth-Identifier: ${IDENTIFIER}" | tee "${OUTPUT}"
シェルスクリプト(サーバーサイド)からの実行では、正常にデータが取得できました。
{
"@context": "https://demo-ig5aiy.frudens.com/fmi/odata/v4/blank01/$metadata",
"value": [
{
"name": "tableA",
"kind": "EntitySet",
"url": "https://demo-ig5aiy.frudens.com/fmi/odata/v4/blank01/tableA"
},
{
"name": "tableB",
"kind": "EntitySet",
"url": "https://demo-ig5aiy.frudens.com/fmi/odata/v4/blank01/tableB"
}
]
}
ブラウザからの実行と CORS エラー
ここが重要なポイントです。認証フロー自体はリダイレクト(ブラウザのページ遷移)で行われるため成功しますが、その後のデータ取得(Fetch API や Axios)は非同期通信で行われます。
FileMaker OData API は CORS(Cross-Origin Resource Sharing) に対応していないため、ブラウザ(JavaScript)から直接 OData API を叩くと、ブラウザのセキュリティ機能(同一生成元ポリシー)によりブロックされます。
つまり、SPA からデータにアクセスするためには、API リクエストを中継する中間サーバー(BFF: Backend For Frontend) またはプロキシが必要不可欠となります。
6. 技術的な考察と課題
検証の結果、仕組みの解明とともに、運用上の注意点も判明しました。
セッションの有効期限とセキュリティ
今回取得した X-FM-Data-OAuth-Identifier は、Google のアクセストークンそのものではなく、FileMaker Server が生成した独自のセッション ID であると推測されます。
FileMaker Server Admin Console の [構成] > [FileMaker クライアント] 設定にある [セッションタイムアウト] がこの Identifier の有効期限に影響するか検証しました。
検証の結果、タイムアウトを10分に設定してもセッションは切断されず、6時間以上経過しても Identifier は有効なまま でした。
このことから、OData API の OAuth セッション(Identifier)は、Admin Console の標準的なクライアントタイムアウト設定の影響を受けない(あるいは非常に長い有効期限が固定されている)可能性が高いです。
FileMaker OData API は標準規格(OData Standard)に準拠していますが、明示的なログアウトのエンドポイントが見当たりません。もし Identifier が実質的に無期限、あるいは長時間有効である場合、フロントエンドでこの値を保持し続けることはセキュリティリスクとなります。
この点からも、BFF レイヤーを設け、Identifier の管理をサーバーサイドで行う構成が望ましいと考えられます。
後日、Claris に連絡して内部仕様について確認を行う予定です。
7. まとめ
今回の検証により、独自の認証ロジックが必要なデメリットはありますが、SPA などのモダンなフレームワークのバックエンドとして FileMaker OData API を利用する道筋が見えました。
検証の結論
-
リダイレクト連携の確立
X-FMS-Return-URLを活用することで、外部 SPA と FileMaker Server 間での認証情報の受け渡しが可能です。 -
BFF(中間サーバー)の必要性
ブラウザの CORS 制限を回避し、Identifier を隠蔽・管理するために、API リクエストを中継するサーバーが必須となります。 -
セキュリティリスクへの対応
Identifier の有効期限が長いため、フロントエンドに直接露出させず、サーバーサイドで厳重に管理する設計が求められます。
「SPA から直接接続する」という完全なサーバーレス構成は難しいものの、適切なアーキテクチャを採用することで、FileMaker のデータを活用した高機能な Web アプリケーションは十分実現可能です。
FileMaker と Web の連携でお困りですか?
本記事のような API 連携やシステム構築について、技術的なサポートを行っております。「実現したいことはあるが、技術的なハードルが高い」とお悩みの方は、ぜひ無料相談からお気軽にご連絡ください。
- FileMaker と Web アプリケーションをセキュアに連携させたい
- EC サイト運用や業務フローの自動化(スクレイピング等)を検討している
- 既存の FileMaker 資産を活かして、モダンな Web サービスを構築したい

