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

公開日： 更新日：

目次

この記事のポイント

  • FileMaker Data API を SPA から安全に利用するためのアーキテクチャ
  • OAuth 認証利用時における OData API と Data API のセッション管理の違い
  • Cloudflare Workers を活用した CORS 対策とセキュリティ向上

1. はじめに

先日投稿した記事にて、FileMaker Data API および FileMaker OData API で OAuth 認証を利用する際のフローや課題について調査結果を共有しました。

そもそも、このような技術調査を始めたきっかけは、「FileMaker の Web 化」や「FileMaker の API に外部の Web アプリから安全にアクセスしたい」というご相談をいただいたことでした。

その解決策の一環として、今回は実際に Angular（CSR/SPA）を使用し、認証フローを含む簡易的なデモアプリケーションを作成しました。本記事では、検証用デモの動作と、Web アプリ連携における重要なポイントをお伝えします。

今回の検証により、独自の認証ロジックが必要なデメリットはありますが、SPA などのモダンなフレームワークのバックエンドとして FileMaker OData API を利用する道筋が見えました。

「SPA から直接接続する」という完全なサーバーレス構成は難しいものの、適切なアーキテクチャを採用することで、FileMaker のデータを活用した高機能な Web アプリケーションは十分実現可能です。

FileMaker OData API を外部ドメイン（SPA）から OAuth 認証で利用する際の認証フローの調査と検証 | 株式会社フルーデンス

2. 「FileMaker の Web 化」における課題とアプローチ

一口に「FileMaker の Web 化」と言っても、どのような課題を解決したいかによって、適切なアプローチは異なります。

主な課題と解決の方向性

よくお聞きするのは以下のような課題です。目的によって手段が全く異なる点に注意が必要です。

課題

  • デバイス活用の拡大
    簡易的な業務のためだけに FileMaker Pro をインストールしたくない、または Android デバイスを活用したいケース。
  • コストの最適化
    ライセンスコストを削減したい、あるいは将来的に FileMaker からの移行を検討しているケース。

「Android デバイスを活用したい」場合、Web アプリケーションを作成し、バックエンドのデータソースとして FileMaker を継続利用する構成が有力です。

ただし、単に Android デバイス等で利用したいだけであれば、FileMaker WebDirect という標準機能が存在します。そのため、前者の「デバイス活用の拡大」という意図だけで、あえてスクラッチでの Web 化を進めるケースは少ないでしょう。今回のような API 連携は、WebDirect では実現できない UI/UX 要件や、不特定多数への公開が必要な場合に選択されます。

一方、「コストを削減したい」場合は、将来的に FileMaker を利用しない方向へシフトすることを意味します。つまり、一般的な Web アプリケーション開発と同様に、バックエンドのデータベースに PostgreSQL などを採用し、認証には Amazon Cognito や Auth0 などの IDaaS を利用する構成へ移行することになります。過渡期として、部分的に FileMaker Data API を利用するハイブリッドな構成も選択肢の一つです。

3. FileMaker Data API 公開時のセキュリティ対策

FileMaker Data API を利用するには、ポート 443 で外部公開する必要があります。ここで OAuth を利用せず、FileMaker 標準のユーザー認証（パスワード認証）のみで運用する場合、Basic 認証と同等の強度しか持ちません。適切なパスワードポリシーやユーザー管理が行われていない場合、外部からの不正ログインを許すリスクが高まります。

また、Cloudflare などの CDN/WAF を前面に配置せず、ドメインの A レコードでオリジンサーバー（FileMaker Server）の IP アドレスが露出している場合、DDoS 攻撃などを容易に受ける可能性があります。

したがって、以下のセキュリティ対策は必須と言えます。

セキュリティ対策

  • Cloudflare などの CDN を配置し、適切なファイアウォールルールを設定する
  • FileMaker 標準のパスワード認証を無効化し、OAuth ID プロバイダ（Google Workspace や Microsoft Entra ID 等）による認証を強制する

社内で既に Google Workspace などを導入している場合、Google 側でアカウント管理を一元化するだけで、退職者のアクセス遮断などが確実に行え、不正ログインのリスクを大幅に低減できます。

4. OAuth 認証とセッション維持の課題

CORS 問題への対処

以前の記事でも言及しましたが、FileMaker Data API には CORS（Cross-Origin Resource Sharing）の制約があります。そのため、SPA など異なるオリジンから API をリクエストする場合、プロキシサーバーが必要になります。今回の検証では、Cloudflare Workers をプロキシとして実装しました。

API トークンとセッション管理

Claris へ問い合わせたところ、ドキュメントの記載が不足している部分については今後更新される可能性があるとのことでした。

前回の記事で懸念点となったのが認証情報の有効期限です。FileMaker OData API で OAuth 認証を行う場合、ID プロバイダが発行したアクセストークンの有効期限（一般的に1時間）に依存します。トークンが延長されない場合、1時間ごとに再ログインが必要となります。

一方、FileMaker Data API は、ログイン時に独自の「セッショントークン」を発行する仕組みです。Validate Session エンドポイントへ定期的にリクエストを送ることで、セッションの有効期限を延長し、長期的にログイン状態を維持することが可能です。

また、Data API には明示的な「ログアウト」のエンドポイントも存在します。長期的なログイン維持やセッション管理の柔軟性を考慮すると、現時点では FileMaker Data API の方が Web アプリケーションとの親和性が高いと判断しています。

5. 推奨されない「共有アカウント」運用

Web 化の相談において、AI の回答や FileMaker のセキュリティに詳しくないエンジニアから、「API 用の共通アカウント（1つの ID/パスワード）を発行し、バックエンド側でその情報を使い回す」というアプローチを提案されることがあります。

しかし、この方法は推奨しません。最大の欠点は以下の通りです。

考慮事項

  • FileMaker が持つ詳細なセキュリティ機能（アクセス権セット）を個別に適用できない
  • Get ( アカウント名 ) やログ、レコード修正者などの監査情報がすべて「API ユーザー」となり、誰が操作したか追跡不能になる

セキュリティと監査の観点から、今回紹介しているように、ユーザー個別の OAuth アカウントで認証を行うべきです。

6. 検証デモ Angular × FileMaker Data API

以前の記事の調査結果をもとに、Angular を使用して実装したデモをご紹介します。

Angularで作成したデモアプリケーションのホーム画面
デモアプリケーションのホーム画面。ログイン前の初期状態です。
OAuth認証からData API接続までの検証ステップ画面
認証フロー検証用のUI。認証URLの取得からトークン検証までをステップごとに可視化しています。

実装上の注意

今回のデモでは分かりやすさを優先し、トークン管理に IndexedDB を使用していますが、本番環境ではセキュリティ（XSS 対策など）の観点から、プロキシサーバー経由で HTTP-only Cookie を利用して管理すべきです。

デモ1 - ID プロバイダ（Google）による認証フロー

SPA から Cloudflare Workers 上のプロキシを経由し、Google アカウントで FileMaker へログインするフローです。

動画1 Angular アプリケーションと Google OAuth を用いた認証フロー
Google認証成功後のリダイレクト画面
Google 認証成功後、FileMaker Server へリクエストを転送する前の中間画面。
FileMaker Serverからのコールバック受信画面
Server からのコールバックを受け取り、identifier（識別子）を抽出している様子。

デモ2 - データの参照と更新

ログイン後、FileMaker のデータを一覧表示し、詳細画面で編集・保存する一連の動作です。

動画2 FileMaker Data API を介したデータの参照と更新
取得したデータを表示する連絡先一覧画面
Data API 経由で取得した JSON データを展開した一覧画面。検索フィルターも実装可能です。
データの編集を行う連絡先詳細画面
詳細画面での編集モード。保存時に Data API の Update エンドポイントを叩き、修正日時などを更新します。

7. まとめ

PostgreSQL と API サーバー（Go 言語など）を組み合わせた構成であれば「疎結合」を実現できますが、FileMaker の特性上、データベースと API の実装が密結合になりやすい点は考慮すべきデメリットです。

しかし、適切なセキュリティ対策とアーキテクチャ設計を行うことで、FileMaker の迅速な開発力を活かした Web アプリケーション開発は十分に可能です。

まとめ

  • セキュリティ
    Cloudflare と OAuth 認証の併用により、不正アクセスや攻撃のリスクを最小化する。
  • API の選択
    セッション維持（キープアライブ）の観点から、現状では OData API よりも Data API の方が SPA に適している場合が多い。
  • 監査ログ
    共有アカウントは避け、個別の OAuth 認証を利用することで、操作ログの透明性を確保する。

FileMaker と Web アプリの連携でお困りですか？

本記事でご紹介した SPA（Angular/React/Vue）との連携や、FileMaker Data API を活用したセキュアなシステム構築について、技術的なサポートを行っております。「認証フローの設計に不安がある」「クラウド環境でのセキュリティを強化したい」とお悩みの方は、ぜひ無料相談からお気軽にご連絡ください。

小巻旭洋のプロフィール写真

小巻 旭洋

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