osFoundry / Platform
来訪者認証
公開アプリ向けに、匿名、マジックリンク、OAuth、ワークスペースSSOを用意。ルートごとに混在可能。
概要
訪問者認証は、osFoundryで公開したアプリの各ルートに誰が到達できるかを決める仕組みです。ワークスペースからアプリを公開すると、公開URLで配信され、ルートごとに独自の入り口を持たせられます。あるページは匿名の訪問者に完全に開放し、別のルートはメールアドレス宛てに送るマジックリンクの背後に置き、OAuthプロバイダーでのサインインを必須にし、あるルートはSSO経由でosFoundryワークスペースのメンバーだけに限定する、といった具合です。アプリ全体で一律に決めるのではなくルート単位で選べるため、マーケティング用のランディングページ、認証で保護したツール、内部向けの管理画面を、同じデプロイの中でそれぞれ別のルールのもとに同居させられます。
osFoundryでは、アプリとその認証は、チャットやエージェント、コード、データと同じワークスペースの中に置かれます。別途アイデンティティサービスを立ち上げたり、セッション処理を手書きしたりする必要はありません。ルートに方式を割り当てると、プラットフォームがリクエストのたびにアプリの手前でそれを適用します。osFoundryはBYOKでローカルファーストのワークスペースなので、この認証の選択はあくまで公開アプリに誰が到達するかを決めるものです。モデルのトラフィックをリセラー経由にすることもなければ、サインインした人ごとに席数課金を上乗せすることもありません。匿名アクセスは本当に匿名のまま保たれ、マジックリンクはパスワードを一切必要とせず、OAuthは訪問者がすでに持っているアカウントを再利用し、ワークスペースSSOは内部ツールをチームの範囲内に閉じておきます。
理解しておく価値があるのは、この「ルートごとに組み合わせる」という考え方です。一つの公開アプリに一律の入り口が向いていることはほとんどありません。訪問者認証を使えば、公開アプリは表向きを開放したまま、その背後の操作を保護できます。内部アプリはSSO限定のままにできます。しかもアプリを別々のデプロイに分割したり、ページごとに専用のミドルウェアを書いたりする必要はありません。
主な機能
- 匿名アクセス：ランディングページや読み取り専用ビュー向けに、サインインなしで公開ルートを完全に開放
- マジックリンクによるサインイン：ワンタイムのリンクをメールで送って訪問者を認証、保存やリセットが必要なパスワードは不要
- OAuth：訪問者がすでに持っているOAuthプロバイダーのアカウントでサインイン
- ワークスペースSSO：内部ツール向けに、ルートをosFoundryワークスペースのメンバーに限定
- ルート単位の設定：同じ公開アプリの中で、ルートごとに異なる認証方式を適用
活用例
- 個人開発者：匿名で開いたランディングページを持つツールを公開し、実際のジェネレーター部分はマジックリンクの背後に置いて、利用をメールアドレスにひも付ける
- チームリード：ワークスペースから内部向けダッシュボードを公開し、すべてのルートをワークスペースSSOで施錠して、同僚だけが開けるようにする
- プロダクトチーム：一つの公開アプリで、ドキュメントは匿名、無料ツールはOAuthサインイン、管理パネルはワークスペース限定、という構成を運用する
よくある質問
同じアプリのページごとに、別々のサインイン方式を使えますか
使えます。訪問者認証はルート単位で設定するため、一つの公開アプリの中で、あるルートは匿名のままにし、別のルートはマジックリンクやOAuthで保護し、さらに別のルートはワークスペースSSOに限定できます。別々のデプロイに分割する必要はありません。
ここでのOAuthとワークスペースSSOの違いは何ですか
OAuthは、外部の訪問者がすでに持っているOAuthプロバイダーのアカウントでサインインできる方式で、公開アプリに向いています。ワークスペースSSOはルートをosFoundryワークスペースのメンバーに限定するもので、一般に到達させたくない内部ツールに向いています。
認証済みの訪問者を追加すると、席数ごとの課金が発生しますか
発生しません。osFoundryに席数課金はなく、訪問者認証は公開アプリに誰が到達するかを制御するもので、サインインした人ごとに課金を上乗せするものではありません。これはワークスペースのApps & Backendレイヤーの一部であり、別立てのアイデンティティ契約ではありません。