Nextcloud SAML 認証で WebDAV が問題になる理由 – SSO とアプリパスワードを分けて考える

Nextcloud を Keycloak などの IdP と SAML 連携させると、ブラウザからのログインはかなりきれいに統合できます。SSO としては自然で、ユーザー体験も分かりやすいです。

一方で、Nextcloud には WebDAV という重要なアクセス経路があります。ここで問題になるのは、SAML 認証そのものの良し悪しではなく、ブラウザ前提の SSO と WebDAV クライアントの認証方式が同じではないことです。

つまり、ブラウザで SSO できることと、WebDAV や同期クライアントが同じ認証フローで動くことは別問題です。Nextcloud の認証設計では、入口ごとに責任分界を分けて考える必要があります。

発生する問題

私の環境では、Nextcloud を Keycloak の SAML と連携し、ブラウザでは問題なく認証できるようになりました。Mac や iPhone のクライアントからも利用できる状態でした。

しかし、WebDAV を SAML 認証のまま使おうとすると問題が出ます。WebDAV クライアントが SAML のリダイレクト、IdP 側のログイン、セッション確立といったブラウザ前提の流れを理解してくれるとは限らないためです。

• ブラウザでは SAML のリダイレクトを追跡できる
• WebDAV クライアントはユーザー名とパスワードを前提にすることが多い
• OS 標準の WebDAV マウント機能は SSO フローに弱い場合がある
• 結果として、ブラウザではログインできるのに WebDAV では認証できない状態が起きる

SAML はブラウザ向けの認証フローである

SAML は、組織内の認証基盤と Web アプリケーションを統合するには強力です。ただし、その強さは主にブラウザを前提にしたリダイレクト型の認証フローにあります。

利用者が Nextcloud にアクセスすると、Nextcloud から IdP にリダイレクトされ、IdP で認証し、認証結果を受け取って Nextcloud 側のセッションが確立されます。この流れはブラウザであれば自然に扱えます。

しかし WebDAV クライアントは、ファイル操作のために HTTP リクエストを投げるだけの実装であることが多く、ブラウザのような SAML フローを前提にしていません。

WebDAV は別のアクセス経路として扱う

Nextcloud の WebDAV は、ブラウザ UI とは別の入口です。ファイルマネージャー、同期クライアント、バックアップアプリ、モバイルアプリなど、さまざまなクライアントが利用します。

そのため、Nextcloud の認証設計では、ブラウザログイン、Desktop Client、WebDAV マウント、モバイルアプリを同じものとして扱わない方がよいです。

アクセス経路	認証の考え方	設計上の注意
ブラウザログイン	SAML / OIDC による SSO と相性がよい	IdP へのリダイレクトとセッション確立を前提にできる
Nextcloud Desktop Client	Nextcloud 側のクライアント認証方式に従う	SSO 連携時は実際のクライアント挙動を確認する
WebDAV マウント	アプリパスワード前提で考える方が現実的	OS 標準クライアントが SAML フローを扱えるとは限らない
モバイルアプリ	アプリ側の認証対応に依存する	ブラウザと同じ体験になるとは限らない

WebDAV はアプリパスワードで考える

SAML で Nextcloud のブラウザログインを統合しても、WebDAV クライアントには別途アプリパスワードを発行して使う、という確認が現実的です。

WebDAV の URL は、例えば https://cloud.example.com/remote.php/dav/files/USERNAME/ のような形になります。実際のクライアント設定では、Nextcloud のユーザー名と、通常のログインパスワードではなくアプリパスワードを使う形に分けます。

この分け方により、ブラウザログインは SAML / OIDC で統合しつつ、WebDAV はクライアント向けの資格情報として扱えます。

アプリパスワードは逃げではない

SSO を導入したのにアプリパスワードを使うのは後退のように見えるかもしれません。しかし、これは認証経路を分けるための現実的な設計です。

ブラウザで利用する SSO と、非ブラウザクライアントが使う資格情報は、そもそも前提が違います。すべてを一つの認証フローに統一しようとすると、かえって運用が不安定になります。

大事なのは、アプリパスワードを無秩序に増やすことではありません。どのクライアントに発行し、不要になったら無効化し、必要に応じて監査できるようにすることです。

Mac Finder の WebDAV とは別の問題でもある

Mac Finder から WebDAV をマウントすると遅い、という問題もあります。これは認証以前に、Finder と WebDAV の体感性能や使い勝手の問題です。

SAML 認証の問題は、そこからさらに別の層にあります。たとえ WebDAV の速度が十分でも、クライアントが SAML フローを扱えなければ認証で詰まります。

そのため、Nextcloud を Mac から使う場合は、Finder の WebDAV マウント、Nextcloud Desktop Client、Samba / SMB、ローカルストレージの役割を分けて考える必要があります。

Keycloak 連携では責任分界が重要になる

Keycloak を IdP として使う場合、Keycloak は認証連携のハブになります。一方で、Nextcloud 側には WebDAV、アプリパスワード、ユーザー管理、グループ、クライアント連携の都合が残ります。

つまり、Keycloak を入れれば Nextcloud のすべての認証経路が綺麗に統合されるわけではありません。ブラウザ SSO の責任、WebDAV クライアントの責任、アプリパスワードの責任を分ける必要があります。

この分離は、SAML / OIDC が弱いという意味ではありません。ブラウザ向け SSO と非ブラウザクライアントの認証を、同じものとして扱わない方がよいという話です。

関連記事

• Keycloak を利用した認証基盤の統合 – LDAP / Nextcloud / Kubernetes をどうつなぐか
• LDAP より SAML/OIDC が高セキュリティという幻想 – 認証方式は適材適所で選ぶ
• Mac Finder の WebDAV アクセスが遅い理由 – Nextcloud は同期と WebDAV を分けて考える
• Nextcloud に .DS_Store が同期される問題 – Mac と共有ストレージのメタデータをどう扱うか
• Mac のローカルストレージをどう考えるか – Samba / Nextcloud 時代のファイル運用

まとめ

Nextcloud を SAML 認証と連携すると、ブラウザログインはきれいに SSO 化できます。しかし、WebDAV や同期クライアントが同じ認証フローで動くとは限りません。

WebDAV はブラウザとは別のアクセス経路であり、アプリパスワードを使う前提で確認する方が現実的です。これは SSO からの後退ではなく、アクセス経路ごとの責任分界です。

Nextcloud の認証設計では、ブラウザ SSO、WebDAV、Desktop Client、モバイルアプリを分けて考える必要があります。SAML / OIDC を導入すること自体より、どの経路にどの認証方式を使わせるかを明確にすることが重要です。

関連する記事