認証プロバイダーで全アプリを統合管理！運用をスマートにする「認証の一元化」戦略

同じく。自分もollama + openwebuiのスタックを追加したよ。OIDCの設定は2分もかからなかった。ドキュメントをコピペするだけ。

それな。Autheliaのドキュメントにあるインテグレーションの章はすごく分かりやすい。

Authelia + LLDAPの組み合わせに1票。

自分も全く同じことしてるよ。最近は自分でアプリを開発することが増えてきたから、その要件として（SSO対応を）追加するようにしてる。

OIDCがないなら、forwardauthを使うのはどう？

多分そうなんだけど、自分には使いこなすのが難しすぎる。ドキュメントも役に立たないし、本当に試してみたんだけどダメだった。あと、リバースプロキシ経由で追加すると、モバイルアプリが動かなくなる可能性が高いんだよね。

navidromeってhttps接続かな？それとも独自のポート使ってる？独自のポートなら問題ないかもしれないね。

どうだろうね。自分はそこまで辿り着けなかったな。提案された解決策を何時間もいじってみたけど、全然うまく動かなくてさ。

ちなみに、NPMでリバースプロキシを組んでqbittorrentとかを守ってるんだけど、なぜかNavidromeのログインをauthentikのヘッダーと接続させるのが異常に難しかったんだよね。

APIエンドポイントのフォワード認証はバイパスできるよ。

ブラウザ上では自動ログインされるから、Navidrome内のパスワードがAPIキーみたいな役割になって、アプリでも使えるようになる。自分はそれ用にすごく長くてランダムなパスワードを作ったよ。

追記：まあ、めちゃくちゃな回避策の一つかもしれないけどね。

提案の意味がよくわからないんだけど。

理論上はNavidromeのログインを完全に無効化して、Authentikの認証壁の裏に隠すことはできるよ。自分はqBittorrentでそれをやってる。

ただ、そうするとマルチユーザーアクセスができなくなるのが難点だね…

https://www.navidrome.org/docs/usage/integration/authentication/#configuration

外部認証を有効にすると、Navidromeは受信リクエストのRemote-User HTTPヘッダーから認証済みユーザー名を取得する。ヘッダー名はExtAuth.UserHeader設定オプションで変更可能。

プロキシを設定して /rest/* URLへの認証をバイパスし、それらのリクエストはNavidrome側で認証を行うこともできる。

同じやり方でいけるはずだよ。NavidromeがRemote-Userヘッダーを読み取れるようになればマルチユーザーアクセスも維持できるし。Authentik側ではヘッダー名が違うかもしれないけどね。

それがうまくいったら、APIの認証をバイパスするルールを作成すればいい。

あと、リバースプロキシ経由で追加するとモバイルアプリが動かなくなる可能性が高いんだよね。

https://www.navidrome.org/docs/getting-started/extauth-quickstart/

ここを見る限り、/share/ と /rest/ をホワイトリストに入れれば良さそうだけど。

それだとアプリが壊れると思うよ。でもカスタムヘッダーならいけるはず。

ああ、自分の環境でもやったよ。でも一部のパスは除外しないとアプリが動かなくなるから気をつけて。

/rest エンドポイントでOIDCをバイパスできるようにすれば、Web版はOIDCで認証しつつ、Subsonic対応アプリはNavidromeで設定したパスワードで動くはずだよ。APIがOIDCスタックで保護されないという意味では理想的ではないけど、APIにはよくあることだしね。Navidromeのパスワードをユーザー設定可能なAPIキーとして扱うようなものだよ。これでユーザーはWeb版ではSSOを使って操作できるはずだし、それが一番の懸念点だったんだよね。

ああ、できる限りAuthentikをブループリントと一緒に使ってるよ。

OIDCを使い始めると、その便利さがすぐ分かるよ。逆にnavidromeとかjellyfinみたいに、未対応の有名アプリにぶち当たった時にね。

Jellyfinは対応してなかったっけ？確かプラグイン経由だった気がするけど。

「今誰がログインしているか」みたいなコアかつクリティカルな機能は、サードパーティのプラグインに任せるべきじゃないでしょ。（https://github.com/9p4/jellyfin-plugin-sso ）いつサポート終了になってもおかしくないしね。それにこれだとウェブでしか使えないし。Plexを本気で置き換えるなら、どこでもOIDCが使える状態じゃないとね。Plexはそれができてるんだから。

残念ながらそのプラグイン、アーカイブされちゃったんだよね。

なるほど。

少なくともLDAPプラグインは公式でまだ使えるから、ないよりはマシだよね。

君の投稿で初めて知ったわ。それは残念。今使ってるけど、Jellyfinが互換性を切った瞬間に（少し前にあったけど）もう終わりだな。

少なくともldapはまだ使えるからな。

自分も全く同じ状況。自分以外が使うものをホストするならOIDCは必須だよね。みんなNavidromeやSubsonicがSpotifyの代替になるって言うけど、SSOがないと自分には無理。あと、AuthentikからPocketID/Tinyauthに乗り換えたんだけど、めちゃくちゃ快適。Authentikの機能の10%しかできないけど、たぶん自分が必要なのは5%くらいだしね。パスワードからパスキーへの移行は最高だよ。かなりおすすめ。

PocketIDは最高だけど気をつけて。職場や他のパソコンからログインできなくなる可能性がある。自分の場合、Edgeだと大抵ハードウェアキーでのログインオプションは出るけど、パスキーやTOTPは許可されないことがあるんだ。

仕事用の端末や自宅の特定のPCでランダムに発生するんだけど、原因は結局わからずじまいで…

パスキー自体は素晴らしいけど、パスキーオンリーっていうのは使い勝手が悪いな。

パスワードやTOTPでログインできるなら自分もPocketIDに乗り換えるんだけど。

仕事用のPCではそんなこと起きたことないから、間違いなく企業のEdgeポリシーかなにかが影響してるね。まあメールコードでログインすることもできるはずだし、手間はかかるけど動くはずだよ。SMTPプロバイダーが必要になるから、smtp2goがおすすめ。あと、仕事用のPCから自分のホームラボにログインするなよ、バカめ😅

なんでダメなの？仕事中にNextcloudのデータが必要なんだよ。どのみちPangolinの背後にあるし。

個人のシステムと仕事のシステムを混ぜると、いろいろ面倒なことが起こるよ。会社のポリシー違反になったり、片方のマルウェアがもう片方に影響したり、仕事用PCで監視されたりとかね。

それな、自分もイライラするわ。たぶんSubsonic APIへの対応の名残なんじゃないか？

PocketIDに一票。
最初はAutheliaにしようと思ったんだけど、サービス10個分を設定する手間を考えたら代替案を探す気になってね。PocketIDを見つけて試したけど、セットアップはめちゃくちゃ簡単だし、UI/UXもPasskey対応で優れてる。Autheliaとかに比べるとかなり軽量だよ。

検証用にAutheliaとauthentikを基本SSO設定で入れてるけど、腰を据えてしっかり理解して記憶し続けるのがなかなか大変でね。PocketIDの方がずっと簡単そうだからチェックしてみるよ。

AutheliaはForwardAuthみたいに認証システムのサポート範囲が広いけど、その分複雑になる。Pocket-IDがパスキー専用っていうのは（個人的には）強みだと思う。設定も体験も簡潔になるし、パスワードの管理に悩まされることが一生なくなるからね。

自分もAuthentikの設定でやる気が出なくて、2回諦めた経験があるよ。Pocket IDはめちゃくちゃ簡単で最高だった。

まだ始めたばかりだけど、Pocket IDは最高だね。サービスを追加すれば、ほぼ一瞬でみんながアクセスできるようになるんだから。大学で（ひどいやり方の）LDAPやOIDCをなんとなく見たことがある程度の初心者からの意見だけどね。

唯一気に入らないのは、Jellyfinがネイティブ対応してなくて、対応させてた唯一の拡張機能もアーカイブされちゃったことかな。

Pocket IDは2回失敗して、パスキーを設定してたアプリから締め出されたことがある。100% Pocket IDのせいとは言い切れないし、去年のあの時はセットアップかDBの問題だったのかもしれないけど……何にせよ、今はCloudflareのアプリとポリシーを使う方が好みかな。

面白いね！昨日ちょうどJellyfinでLDAPプラグインを使うためにLDAPのセットアップをしてて、だいぶ時間を食ったところだよ。面倒だったけど、とりあえずうまく動いてるみたい。

OIDCをサポートしてないアプリはどうしてる？

自分はCaddyでForwardAuthを使ってる。他の人だとtinyauthとか、似たようなソリューションでうまくいってるみたいだね。

逆の意見も言っておくと、Ansibleですべてのサービスを構成したい自分としては、Pocket IDよりAutheliaの方がニーズに合ってるかな。最初はパスキーだけでいけるからPocket IDで始めたけど、結局IaC環境を完璧に構築したくてAutheliaに乗り換えたよ。

パスキーのみっていう制約が、見た目以上に仕事してるね。Autheliaで環境作ってた時は、柔軟すぎることが逆に問題になってた。結局半分がTOTP、2つがWebAuthn、みたいな状態になって、自分ですら新しいサービスを追加する時の手順がバラバラで混乱してたし。選択肢をあえて絞るプロバイダーの方が、信頼して導入しやすいよね。

セキュリティ面はどうなの？詳しい人による監査とかレビューってある？Authentikは一応ちゃんとした会社がバックについてるみたいだけど、実際のところどうなんだろうね。

最初使い始めた時、PocketIDでちょっと躓いちゃったんだよね。完全に自分のミスなんだけど。とりあえずの繋ぎでTinyauthを使ってるよ。

「パスキーはユーザーにとって遥かに便利」という意見には全面的に同意しかねるな。特定のユースケースでは最高だけど、そうじゃない場面では最悪だよ。

なるほどね、絶対的な言い方をするつもりはなかったよ。ただ、ユニークで強力なパスワードを管理するのは普通のユーザーには非常に難しいし、それが不要になるのは間違いなく大きなメリットだと思う。パスキーに短所がある状況があるのは間違いないけど、それらはあくまで例外的なケースで、大半の場合は最初からパスキーを採用する合理性があると思ってる。もちろん、自分にとってパスワードを使うのが合理的だと思えばそうすればいいさ。

OIDC非対応のアプリについては、こんな感じでやるといいよ：

services:
  bento-pdf:
    image: ghcr.io/alam00000/bentopdf-simple:latest # 推奨
    # image: bentopdfteam/bentopdf:latest     # 代替: Docker Hub
    container_name: bento-pdf
    restart: unless-stopped
    #ports:
    #  - '40000:8080'
    networks:
      - bentopdf_net

  bento-pdf-oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy:latest
    container_name: bento-pdf-oauth2-proxy
    restart: unless-stopped
    command: --config=/oauth2-proxy.cfg
    volumes:
      - /srv/appdata/Docker/bento-pdf/oauth2-proxy.cfg:/oauth2-proxy.cfg:ro
    ports:
      - "40000:4180"
    networks:
      - bentopdf_net

networks:
  bentopdf_net:
    driver: bridge

そして .cfg ファイル：

########################################
# OIDC / PocketID
########################################

provider         = "oidc"
oidc_issuer_url  = "https://id.example.com"
client_id        = "id-from-pocketid"
client_secret    = "secret-from-pocketid"
redirect_url     = "https://pdf.example.com/oauth2/callback"

# PocketIDにID情報を問い合わせる
scope            = "openid email profile"

########################################
# アップストリーム (Bento PDF)
########################################

upstreams        = ["http://bento-pdf:8080"]

# 他のリバースプロキシ (Nginx/Caddyなど) の背後にいる場合
reverse_proxy    = true

########################################
# クッキー
########################################

# 以下を使って32バイトのランダムなbase64文字列を生成する:
# python - << 'EOF'
# import os, base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())

アプリごとに設定するのは少し手間だけど、一度やってしまえば終わりだからね。

自分はoauth2-proxyからtinyauthに乗り換えたよ。似たようなもんだね。tinyauthの設定を一度pocket idですれば、あとは必要なサービスにシンプルなアノテーション（k3s/traefik）を追加するだけだから楽だよ。

あー、そういうことね。了解。じゃあTinyauthを見てみるよ。

Pythonに関してだけど、暗号化関連の機能にはrandomモジュールよりsecrets module を使うのが推奨されてる。例：>>> import secrets; secrets.token_urlsafe(32) 'gaHjLxVgPm1RSJ8Jj-1O1tZxIonA3JqoZWJicE_UeAE' もしくはhexの方が良ければ（opensslコマンドを使うガイドが多いみたいに）：>>> import secrets; secrets.token_hex(32) '0c005a6631b6875ab67cfc1b5558a34c58c08f84a284b7a5beb08c08e6af9af5'

自分もPocketIDにはかなり満足してる。セットアップも使い勝手も簡単だしね。

Pocket-IDに1票。自分はPangolin（Traefik込み）と一緒に使ってる。Pangolinを使うとルーティングや証明書、ルール、バイパス設定が楽だからPocket-IDとの相性もいいんだ。例えばSeafileとOnlyOfficeを併用するとき、ブラウザでファイルを編集・保存できるようにするために、一連のバイパスルールを作って連携させる必要があったよ。

OIDCに対応していないいくつかのサービスのために、TinyAuthを実装しようと思っていたところだよ。

驚くほどシンプルで、認証やOIDCについて考えさせられたよ。多くのプロバイダーが認証機能とID管理機能を統合しちゃってるけど、それは本来あるべき姿じゃないって気づかされたね。で、OIDCを実装しているほぼ全ての場所が、独自の認証プロバイダーを内蔵していることにも気づいたんだ。いっそ全部フォワード認証だけで対応してくれればいいのに、って思っちゃうよxD。

自分もPocketIDとLLDAPを使ってるけど、OIDC非対応のアプリにはtinyauthを使ってる。

tinyauthは不要だよ。認証機能がないサービスを守るなら、Traefikのこのミドルウェアが使えるよ。

https://traefik-oidc-auth.sevensolutions.cc/docs/getting-started

Keycloakとスムーズに連携できないツールを使うために、別のものに乗り換えたの？自分は仕事でKeycloakを使っていて、その経験があるから自宅の認証もKeycloakにしたんだよね。理想を言えば認証基盤は1つにまとめたいし。

同じく。自分も仕事でKeycloakを使っているから自宅にもデプロイしたんだけど、Homepageみたいに認証機能がないものに対しても認証をかけられる仕組みが必要なんだよね。

PangolinもNavidromeも詳しくないんだけど、信頼できるソースの設定はもう済んでる？設定されていればリバースプロキシがHTTPリクエストに追加ヘッダーを付与して、バックエンド側で実際のIPを判断できるようになるはず。今の状態でパブリックIPが見えてるってことは、既にその仕組みが動いてるのかもね。