FileMaker OData API を外部ドメイン(SPA)から OAuth 認証で利用する際の認証フローの調査と検証

公開日: 更新日:

更新履歴

2026年01月23日 追記

本記事の検証結果を元に、Angular (SPA) を使用した実装デモを作成しました。

SPA(Angular)から FileMaker Data API を安全に使うための OAuth 認証とセキュリティ構成

目次

この記事のポイント

  • 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 エンドポイントから対応する応答を受け取ります。

OAuth アイデンティティプロバイダを使用したデータベースセッションへのログイン

公式ドキュメントを読み解きながら、実際に接続できるか検証を行います。

認証フローの全体像

検証の結果判明した、正常な認証フローをシーケンス図に整理しました。SPA が Google からのコールバックを一度受け取り、即座に FileMaker Server(FMS)へ転送する流れになります。

sequenceDiagram autonumber actor User as ユーザー(ブラウザ) participant SPA as SPA
(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エラーになる
SPA を経由する認証プロセスのシーケンス図

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}"
get_oauth_provider_info.sh

レスポンスとして、プロバイダ設定(Google)の情報が返ってきます。ここで ProviderIDAuthType などのパラメータを確認します。

{
  "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
}
response_provider_info.json

3. 認証用URLとリクエストIDの取得

次に、実際の認証プロセスを開始するためのURLを生成します。ここで重要なのは、X-FMS-Return-URLFileMaker 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}"
get_auth_url.sh

実行すると、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=.
response_auth_url.txt

同時に出力されたヘッダファイルを確認し、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

response_auth_headers.txt

この 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-idstate 内にも格納され、認証フロー全体を通して引き継がれている様子が見て取れます。

4. 認証フローと Identifier の取得

取得した認証 URL にブラウザでアクセスし、Google アカウントでログインします。

Google アカウントのログイン画面
認証用URLへアクセスした際の Google ログイン画面

リダイレクトの挙動

認証成功後のリダイレクトチェーンは以下のようになります。

認証とリダイレクトの流れ

  1. Google -> SPA
    Google での認証後、SPA(/oauth/redirect)へ戻ります。
  2. SPA -> FMS
    SPA は受け取った認証コードを持って、FileMaker Server(/oauth/redirect)へリダイレクト(転送)します。
  3. トークン発行とIdentifier生成
    FMS 内部で認証コードからトークンとセッション(Identifier)を生成します。
  4. FMS -> SPA(最終リダイレクト)
    Step 3 で指定した X-FMS-Return-URLhttps://redirect.frudens.com/my/callback)へリダイレクトされます。
  5. パラメータの受け取り
    リダイレクト時の URL パラメータに identifier が付与されます。

Step 4-1. Google から SPA へ

Google でのログイン完了後、SPA(/oauth/redirect)にリダイレクトされます。この際、URL パラメータに codestate が含まれています。

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
SPAリダイレクト後のURL例
認証後にリダイレクトされた SPA の画面。長い state パラメータが付与されている。
認証後にリダイレクトされた SPA の画面

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;
}
SPA 内でのリダイレクト処理イメージ

Step 4-3. FileMaker Server での処理とコールバック

SPA からリダイレクトされると、FileMaker Server は認証コードを検証し、トークン発行と Identifier 生成を行います。

ネットワークタブでのリダイレクトフロー(FMSへのリクエスト)
SPA から FMS へリダイレクトされ、処理が行われている様子

Step 4-4. FMS から SPA へ

処理が完了すると、FMS は最初に指定した Return-URL(SPA の /my/callback)へリダイレクトします。この際、URL パラメータに重要な identifier が付与されます。

ネットワークタブでのリダイレクトフロー(SPAへのコールバック)
FMS から SPA へ戻ってきた際のリクエスト。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 にデータベース名を追加します。

テーブルの一覧の取得 | Claris FileMaker OData API ガイド

以下のスクリプトで実行します。

#!/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}"
get_table_list.sh

シェルスクリプト(サーバーサイド)からの実行では、正常にデータが取得できました。

{
  "@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"
    }
  ]
}
response_table_list.json

ブラウザからの実行と CORS エラー

ここが重要なポイントです。認証フロー自体はリダイレクト(ブラウザのページ遷移)で行われるため成功しますが、その後のデータ取得(Fetch API や Axios)は非同期通信で行われます。

FileMaker OData API は CORS(Cross-Origin Resource Sharing) に対応していないため、ブラウザ(JavaScript)から直接 OData API を叩くと、ブラウザのセキュリティ機能(同一生成元ポリシー)によりブロックされます。

ブラウザのコンソールでCORSエラーを確認
ブラウザからの直接アクセスによる CORS エラー

つまり、SPA からデータにアクセスするためには、API リクエストを中継する中間サーバー(BFF: Backend For Frontend) またはプロキシが必要不可欠となります。

6. 技術的な考察と課題

検証の結果、仕組みの解明とともに、運用上の注意点も判明しました。

セッションの有効期限とセキュリティ

今回取得した X-FM-Data-OAuth-Identifier は、Google のアクセストークンそのものではなく、FileMaker Server が生成した独自のセッション ID であると推測されます。

FileMaker Server Admin Console の [構成] > [FileMaker クライアント] 設定にある [セッションタイムアウト] がこの Identifier の有効期限に影響するか検証しました。

FileMaker Server Admin Consoleのセッションタイムアウト設定画面
検証時の FileMaker Server 設定(セッションタイムアウトを10分に設定)

検証の結果、タイムアウトを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 サービスを構築したい
小巻旭洋のプロフィール写真

小巻 旭洋

2014年からフリーランスとして活動し、2016年に株式会社フルーデンスを設立する。FileMaker開発歴は約10年。多数の企業システム構築を手がけ、特にデータベース設計と、JavaScript連携、Web連携、パフォーマンス最適化を専門としています。2025年から、Web業務システム・アプリ開発をメインに開発をしています。