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

目次

• 1. はじめに
• 2. 「FileMaker の Web 化」における課題とアプローチ
• 3. FileMaker Data API 公開時のセキュリティ対策
• 4. OAuth 認証とセッション維持の課題
• 5. 推奨されない「共有アカウント」運用
• 6. 検証デモ Angular × FileMaker Data API
• 7. まとめ

1. はじめに

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

そもそも、このような技術調査を始めたきっかけは、FileMakerのWeb化に関するご相談でした。

FileMakerのAPIに外部のWebアプリから安全にアクセスしたいというご相談もいただきました。

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

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

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

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

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

主な課題と解決の方向性

よくお聞きするのは、次のような課題です。目的によって手段が大きく変わるので、ここは注意してください。

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

ただし、単にAndroidデバイス等で利用したいだけであれば、FileMaker WebDirectという標準機能が存在します。そのため、前者の「デバイス活用の拡大」という意図だけで、あえてスクラッチでのWeb化を進めるケースは少ないと思います。

今回のようなAPI連携は、WebDirectでは実現できないUI/UX要件があるときや、不特定多数へ公開するときに選びます。

一方、「コストを削減したい」場合は、将来的にFileMakerを利用しない方向へシフトすることを意味します。

一般的なWebアプリケーション開発と同様に、バックエンドのデータベースにPostgreSQLなどを採用します。認証にはAmazon CognitoやAuth0などのIDaaSを利用する構成へ移行します。

過渡期として、部分的にFileMaker Data APIを利用するハイブリッドな構成も選択肢の1つです。

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

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

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

この状態では、DDoS攻撃などを容易に受ける可能性があります。

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

社内で既に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/パスワード）を発行する方法を提案されることがあります。

この方法では、バックエンド側でその情報を使い回します。

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

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

6. 検証デモ Angular × FileMaker Data API

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

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

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

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

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

7. まとめ

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

しかし、適切なセキュリティ対策とアーキテクチャを設計すれば、FileMakerの迅速な開発力を活かしたWebアプリケーション開発を十分に実現できます。

FileMaker と Web アプリの連携でお困りの方へ

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