Lorawan-stack: 新しいアカウントアプリを導入します（oauthアプリを置き換えるため）

参照https://github.com/TheThingsIndustries/lorawan-stack/issues/1659

コンソールとoauthプロバイダー間のログイン/ログアウトの混乱の問題全体に関して、これが私の計画です：

• アカウントアプリには（TTSロゴの代わりに）別のAccountロゴを使用し、コンソールにも使用するのと同じヘッダーコンポーネントを使用します（cc @pierreph）
• コンソールとアカウントアプリ用に2つの別々のログイン画面を用意する代わりに、エクスペリエンスをより緊密に結び付ける必要があります。
  
  
  
  • コンソールのログイン画面を削除します/console/login
  
  
  • （有効な）アクセストークンがない場合、コンソールはアカウントアプリのログインページ/account/loginに自動的にリダイレクトします
  
  
  • すでにコンソールログインボタンで行っているように、ログインが成功した後、リダイレクトクエリパラメータを使用してユーザーをコンソールに送り返します
  
  
  • コンソールUIからログアウトすると、保存されているアクセストークンが削除され、アカウントアプリからログアウトされます。 このように、ユーザーはコンソールに再度ログインするために常に自分の資格情報を再入力する必要があります。
    
    
    
    
    
    • これを実行できるようにするには、クロスオリジンリクエストからログアウトをトリガーする方法が必要です（コンソールとアカウントアプリが同じオリジンであることが保証されていないため）
    
    
    
    • v2では、どこからでも参照できるログアウトをトリガーする単純な/users/logoutルートを使用しています
    
    
    
    • CSRFを安全に保ちながら、同じことを達成する方法を検討するのは良いことです
    
    
    
  
  
  • 新しいフローは、v2コンソールのフローとほとんど同じです。 基本的に、コンソールクライアントと承認サーバーの分離を犠牲にして、UXを改善します。これは、コンソールが一種の特殊なケースのクライアントであるため、問題ありません。
  
  
  • 将来、異なるログイン手順を許可する場合は、このフローを修正する必要があるかもしれません
  
  

この計画についての苦情がない場合は、これを実装し始めます。

素晴らしい計画のように聞こえます。 コンソールから明示的にログアウトする必要はなく、UXではOAuthを介してログインしたままにすることに同意しますが、そのように機能します。

クロスオリジンログアウトには何が必要ですか？ それは単純な2段階のアプローチではないでしょうか。 「ページ」からログアウトして、コンソールに保存されているアクセストークンを削除してから、アカウントアプリがログアウトする一般的なログアウトページにリダイレクトしますか？ または、リダイレクトせずにログアウトエンドポイントに投稿しますか？

ログアウトについては、OpenIDConnectのログアウトからインスピレーションを得ることができます。 素晴らしい要約はここにあります： https ：//medium.com/@robert.broeckelmann/openid -connect-logout-eccc73df758f

素晴らしい計画のように聞こえます。 コンソールから明示的にログアウトする必要はなく、UXではOAuthを介してログインしたままにすることに同意しますが、そのように機能します。

クロスオリジンログアウトには何が必要ですか？ それは単純な2段階のアプローチではないでしょうか。 「ページ」からログアウトして、コンソールに保存されているアクセストークンを削除してから、アカウントアプリがログアウトする一般的なログアウトページにリダイレクトしますか？ または、リダイレクトせずにログアウトエンドポイントに投稿しますか？

2段階のアプローチで問題ありません。 私の懸念は、アカウントアプリのログアウトをCSRFで無効にする必要があることでした。つまり、ログアウトリンクを持っている人は誰でも、誰かを自分のアカウントからログアウトするように誘惑する可能性があります。 これは現在、v2スタックでも可能です（
今のところ、これは許容できると思いますが、正確にはベストプラクティスではありません。

私は今、新しいアカウントアプリのためにかなりの作業を行いました：

• コンソールとアカウントアプリで使用できるリファクタリングされたコンポーネントとコンテナ
• 新しい設計を実装しました（応答性を含む）
• プロフィール写真を含む、実装されたプロフィール設定
• 承認管理の実装（表示および取り消し）
• 実装されたセッション管理（表示および取り消し）
• 共有CSSモジュールの依存関係を使用するとレンダリングが空白になる問題を解決する

これは、スタックAPIを使用できるように、アクセストークンをハードコーディングすることで行いました。 アカウントアプリのアクセストークンを取得するための最良の方法がわからないため、現在、適切な実装を進めることができません。
現在、「oauthアプリ」は、oauthサーバーの認証エンドポイント（ログイン、ログアウト、およびアクセストークンを必要としないその他のアカウント関連のエンドポイント）に接続する単なるSPAです。
@htdvisserは、私たちの最初のアイデアは、パスワード付与タイプを使用して、アカウントアプリを個別のoauthクライアントとして使用することであると私に言いました。 私はこれについての議論を開くべきだと思います、なぜなら：

• ソースによっては、「公式」で信頼できるクライアントであっても、パスワード付与タイプは推奨されません。
• 別のログイン画面（oauthプロバイダーのログイン画面の横）が必要になります
• すでにoauthアプリ内で認証を行っているため、別の別のクライアントを使用せずに、oauthプロバイダーから直接アクセストークンを取得する方法があるかどうか疑問に思っています。
• アカウントアプリにパスワード付与を使用する場合は、コンソールにも使用する必要があります

私はすでに@htdvisserに、これの委任された認証/承認の側面全体が私にはやや圧倒的であり、そのようなセキュリティに敏感な問題に責任を負うほどの知識がないと感じていると言いました。

私たちが目指すべきは、公式クライアントの認証フローをネイティブ認証のように感じさせるフローです（他のコメントも参照）。つまり、ログインとログアウトはグローバルであり、クライアントの認証状態と承認プロバイダー。

そのため、アカウントアプリを続行するには、ヘルプと入力が必要です。 これをどのように調整できますか？

ソースによっては、「公式」で信頼できるクライアントであっても、パスワード付与タイプは推奨されません。

はい、パスワードの付与は使用しないでください。ここで仕様と理由を参照してください：

現在＃2148によってブロックされています

ですから、しばらくこれに関わった後、私はいくつかのインプットが必要だと思います。

アカウントアプリの元々のアイデアは、現在のoauthアプリを置き換え、プロファイルとセッションの管理に向けて機能を拡張することでした（OPを参照）。 これに関する問題は、そのような機能を実装するために、アプリがアクセストークンを必要とすることです。つまり、アカウントアプリはOAuthプロバイダーとクライアントの両方になるということです。

私のアイデアは、新しいOAuthクライアント（ account ）をフロントエンドごとに導入して、機能を現在のOAuthアプリとブレンドすることでした。 ユーザーにとっては、OAuthプロバイダー（ログイン、登録、アカウントの検証など）とアカウントアプリクライアント（プロファイル設定、セッション管理、承認管理）の両方が1つの同じアプリケーションであるように見えますが、バックグラウンドではOAuthプロバイダーとクライアントの間の技術的な分離です。 バックエンドでは、アカウントクライアントはoauthパッケージの一部になります。 フロントエンドに関しては、同じエントリポイント（ account.js ）を使用して、両方を同じアプリとして扱うこともできます。
同様に、ルーティングはこのブレンドを反映します。例：

• oauthログイン用の/account/login [OAuthプロバイダーレイヤー]
• ユーザー登録用の/account/register [OAuthプロバイダーレイヤー]
• ユーザー登録用の/account/forgot-password [OAuthプロバイダーレイヤー]
• クライアントログイン用の/account/client/login/ttn-stack （承認）[OAuthクライアントレイヤー]
• /account/client/oauth/callbackは、認証コードを交換します[OAuthクライアントレイヤー]
• /account oauthクライアントの概要ページ[OAuthクライアントレイヤー]

または、両方の懸念事項を分離して、OAuthプロバイダー（ /oauth経由でpkg/oauth ）をそのままにして、アカウントアプリ（ /account経由でpkg/account ）を処理することもできます。 ）コンソールの場合と同様に、完全に別個のものとして。 その場合、OAuthプロバイダーは、承認やユーザーアカウントの登録などの認証の問題にのみ責任を負いますが、現在のように独自の認証されたビューはありません。 代わりに、ログイン後、デフォルトでアカウントアプリにリダイレクトされ、トークンが自動的に取得されます。

最初の解決策は、現在認証とアカウント管理を中心に展開している混乱の一部を回避できると思いますが、それが他の問題を引き起こす可能性があるかどうかは予測できません。 2番目の解決策はよりクリーンに見えますが、問題は分離をどのように伝達/ブランド化するかです。 たとえば、両方とも「アカウントアプリ」としてまだ伝達する必要がありますか？ それともThe Things Stack Single Sign OnとThe Things Stack Account Applicationでしょうか？

ご意見をお聞かせください。

うーん、一歩後退して、アカウントアプリをOAuthクライアントにする目的は何ですか？ OAuthを介してどのような機能が必要ですか？

• プロファイル設定（名前、メールアドレス、プロフィール写真）
• セッション管理（レビュー、取り消し）
• 承認管理（レビュー、取り消し）
• （将来的には他のTTES関連のメタ設定になる可能性があります）

アクセストークンは、それぞれのRPCを承認する唯一の方法であるため、これらすべてにアクセストークンが必要です。

OAuthプロバイダー（たとえば「 TheThings Network Community」などの外部）と、ポイントThingsStackに格納されているユーザーエンティティのフィールドの管理に関するユーザー管理を分離する必要があります。上記のコメントに書いた。

/api/v3/*エンドポイントは、CORSに対応しているため、Cookie認証を受け入れません。 これらは、APIキーとアクセストークンでのみ機能します。

• プロファイル設定（名前、メールアドレス、プロフィール写真）
• セッション管理（レビュー、取り消し）
• 承認管理（レビュー、取り消し）
• （将来的には他のTTES関連のメタ設定になる可能性があります）

アクセストークンは、それぞれのRPCを承認する唯一の方法であるため、これらすべてにアクセストークンが必要です。

コンソールのこれらの部分を作成することもできますが、それはコンソールがある程度の懸念を混合することを意味します。 他のすべてのコンソール機能のオーバーヘッドなしでアカウント管理を実行する方が良い状況を見ることができましたが、おそらくそれは私がこれを過剰に設計していることです🤷‍♂️。

一般的に、問題は、コンソールをネットワーク関連の問題を管理するためのツールとしてのみ見たいかどうかです。 すべてのTTS関連事項の汎用管理プラットフォームとしてオープンにすることも、よりアトミックで分離に固執し、さまざまな懸念事項に対してさまざまなアプリ/クライアントを使用することもできます。 それは戦略的な質問です。 両方のケースがあります。

コンソール（各クラスターにコンソールがあるため、すべてのコンソール）がユーザーに対する完全な権限を持つべきではないと思います。 承認されたOAuthクライアント、セッション、プライマリ電子メールアドレス、連絡先情報を管理するためにコンソールを使用しないでください。 専用のユーザー管理アプリ（アカウントアプリ）を使用する方がはるかに優れています。

確かに、良い点。 次に、最初の質問に戻ります。

私の見解は：

混合アプローチ：

• 混乱の少ないユーザーPOVから（すべてのアカウント関連事項に対して1つの場所）
• より簡単なブランディング/コミュニケーション
• アカウントアプリの当初の計画に準拠
• フロントエンドに関しては、新しいエントリポイントは必要ないため、個別のボイラーメッキが必要です。
• 実装はより複雑/混乱します（アカウントアプリはoauthプロバイダーとクライアントです）

分離されたアプローチ：

• よりクリーンで従来型の実装
• より柔軟で明確な構成
• 賢明なブランディングとコミュニケーションを必要とするoauthアプリの隣に新しいアプリを導入します
• より長いビルド（限界である可能性があり、テストされていない）とより多くのアセット

私は混合アプローチに傾いています。

• プロファイル設定（名前、メールアドレス、プロフィール写真）
• セッション管理（レビュー、取り消し）
• 承認管理（レビュー、取り消し）
• （将来的には他のTTES関連のメタ設定になる可能性があります）

これはアカウントアプリですよね？ OAuthではありませんか？

• 賢明なブランディングとコミュニケーションを必要とするoauthアプリの隣に新しいアプリを導入します

それでもOAuthアプリは何ですか？

OAuthクライアントがアカウントアプリに追加する機能のうち、新しいエンドポイントを介してアカウントアプリに組み込むことができない機能をリストできますか？

これはアカウントアプリですよね？ OAuthではありませんか？

はい、これはアカウントアプリです。 しかし、計画では、OAuthアプリとして現在持っているものがアカウントアプリの一部になる予定でした。

それでもOAuthアプリは何ですか？

認証（OAuthフローの一部として）、ユーザー登録、クライアント認証、パスワードのリセット。 基本的に、ユーザーの認証とクライアントの承認に関係するすべてのもの。

OAuthクライアントがアカウントアプリに追加する機能のうち、新しいエンドポイントを介してアカウントアプリに組み込むことができない機能をリストできますか？

問題はさらに逆で、アクセストークンを取得する必要があるため、現在のOAuthアプリをアカウントアプリに必要な機能で単純に拡張することはできません。 鶏が先か卵が先かという問題です。 アカウントアプリの機能（セッション、承認など）に異なる承認手段があった場合、たとえばOAuthアプリが持つセッションCookieを介した場合、それは異なります。 しかし、私が見るところ、これは実行不可能です。

OAuthアプリはスタンドアロンのものですか？ OAuthクライアントのリダイレクトフローを実装していますか？ それともOAuthクライアント自体ですか？

強調鉱山：

私のアイデアは、新しいOAuthクライアント（ account ）をフロントエンドごとに導入して、機能を現在のOAuthアプリとブレンドすることでした。 ユーザーにとっては、 OAuthプロバイダー（ログイン、登録、アカウントの検証など）とアカウントアプリクライアント（プロファイル設定、セッション管理、承認管理）の両方が1つの同じアプリケーションであるように見えますが、バックグラウンドではOAuthプロバイダーとクライアントの間の技術的な分離です。 バックエンドでは、アカウントクライアントはoauthパッケージの一部になり

ここに見えます。

• OAuthクライアント
• 現在のOAuthアプリ
• OAuthプロバイダー
• アカウントアプリクライアント
• OAuthプロバイダー
• クライアント
• バックエンド
• アカウントクライアント
• oauthパッケージ

私は提案を理解しようとしていますが、まだ何が何であるかを完全には理解していません。

では、必要な機能は何ですか？

1. アカウントを作成する
2. パスワードを忘れる
3. ログイン
4. パスワードを変更する
5. プロファイルの表示と編集
6. セッションを管理する
7. OAuthのもの
   
   
   
   1. 同意画面（OAuth認証コードフロー）
   
   
   2. OAuth認証を管理する
   
   

セッション認証を使用すれば、OAuthにまったく触れずに1〜6を実装できると思います。 それは可能ですよね？

うん、ごめんなさい。 ここには固定されていない用語がいくつかあり、説明が非常に難しくなっています。 少なくとも、問題の複雑さについての良い洞察が得られます😅。

それでは、現状を見てみましょう。

OAuthプロバイダー
OAuth 2.0仕様に従って承認（この場合は認証も）を提供するエンティティ。 この場合、これはpkg/oauthパッケージであり、OAuthアプリ（以下を参照）を使用して、ユーザー情報（ログイン、登録、承認ビューなどのレンダリング）を取得するために必要なユーザーインターフェイスを実装します。

OAuthアプリ
これはフロントエンドのreactWebアプリケーションです。 フロントエンドコードは、reactコンポーネントやユーティリティなどの共通部分を共有するさまざまなアプリ（さまざまなエントリポイントoauth.js / console.js ）で構成されています

OAuthクライアント
コンソールやCLIなど、認証と承認にOAuthを使用する登録済みクライアント。

oauthパッケージ
OAuthプロバイダーの実装を担当するGoパッケージ。 それはpkg/oauthです。

ご覧のとおり、ここでは3つまたは4つの異なるレイヤーが使用されています。 問題は、現時点で承認を行う方法を維持する場合、上記で概説したすべての役割を果たすものを同時に持つ必要があるということです。

セッション認証を使用すれば、OAuthにまったく触れずに1〜6を実装できると思います。 それは可能ですよね？

はい。 1〜4は、oauth /アクセストークンなしですでに可能です。 5と6には現在アクセストークンが必要です。 7.iiはまだ実装されていません。 アクセストークンなしで5と6が可能であれば、これを行うために別のoauthクライアントは必要ありません。 それでも、将来アカウントアプリに追加する可能性のあるすべての機能は、承認の唯一の手段としてアクセストークンを使用してはならないことを考慮する必要があります。

アクセストークンなしで5と6が可能であれば、これを行うために別のoauthクライアントは必要ありません。 それでも、将来アカウントアプリに追加する可能性のあるすべての機能は、承認の唯一の手段としてアクセストークンを使用してはならないことを考慮する必要があります。

右。 これは私には非常に理にかなっています。 これは、たとえばパスワードを再入力した後、ユーザーがアカウントアプリで_only_することができる「sudoモード」のより良い基礎にもなります。 そうです、OAuthクライアントとアカウントアプリでできることには多少の重複があるかもしれませんが、その重複は私には大きく見えません。 アカウントアプリ専用のものを維持することに価値があると思います。

いいですね。
@htdvisser異議はありますか？ そうでない場合は、承認のために相対的なファイル/パッケージを教えていただけますか。これについては、すぐに作業する時間がないと思います（？）。

以前にコメントしたように、 /api/v3/*エンドポイントはCORS対応であるため、Cookie認証を受け入れません。 Cookie認証の受け入れを開始する場合は、CORSヘッダーをよく確認する必要があります。これは、攻撃者がこれらのエンドポイントに対してCookie認証されたクロスオリジンリクエストを行うことを実際に望んでいないためです。

私たちのAPIはすべてgRPCであり、認証はAuthorizationヘッダーを使用して行われ、リクエストメタデータとしてgRPCに伝播されます。 セッション認証の実装は次のようになります。

• SessionTokenタイプをpkg/auth/auth.go追加します
• APIキーとアクセストークンで行うのと同様に、 Sessionモデルに秘密の部分を追加します。
• CookieからセッションIDとセッションシークレットを抽出し、それをSessionTokenとしてAuthorizationヘッダーに転送するミドルウェアを追加します
• caseのswitch tokenType {にpkg/identityserver/entity_access.go case SessionTokenとして

ここで考慮すべきことの1つは、アカウントアプリとv3APIを同じオリジンから提供する必要があることも意味します。 そうしないと、認証コンテキストが異なるオリジンで構成されているため、Cookie認証は機能しません。
それがどれほど受け入れられるかわからない。 少なくとも実際には、展開で同じオリジンを使用しているようです。

はい、それらは同じ起源になります。

@kschifferは、ここで進行状況のブロックを解除する方法を教えてください。

ここに要約を書きました： https ：

OK、ここでその会話を続けましょう。

@kschifferこれに少し取り組ん

• oauthアプリのフロントエンド部分は、基本的に認証画面のみで構成されます

はい

• そのためだけにis.oauth.ui.*設定を保持しなければならないのは非常に面倒だと思います
  [...]
• また、CCを壊さずにスタック構成を変更する方法の正確な制限についても少しわかりません。
• 私はここで実行可能な解決策を見つけるのに少し運が悪いので、本当にいくつかの入力が必要です

V3で構成を解除することはできませんが、新しい構成を導入し、古い構成を廃止し、古い構成をフォールバックとして使用し、 bump/majorというラベルの付いたTODOの問題を提出して、古い構成を削除することはできます。

したがって、私の提案は、完全に置き換えられ、新しいアカウントアプリを有効にする新しい構成を導入することです。 下位互換性のために、ユーザーがこの新しい構成を指定しなくても機能する必要があります。つまり、 is.oauth.ui.*介して正常なデフォルト値と古い構成に依存します。

@kschifferここのステータスは何ですか？

現在、ここで進行中の新しいスキャフォールドに基づいて作業をリベースしています：＃3453

次は、認証されたビューのリベース、修正、PRを行い、現在のデザインを新しいブランドに調整します。

@kschifferここのステータスは何ですか？

アカウントアプリは3.11で導入されました。 現在まだ不足しているのは次のとおりです。

• アカウント切り替え＃488
• セッション管理
• 承認管理（iircこれにはAPIエンドポイントの追加も含まれます）

わかった。 https://github.com/TheThingsNetwork/lorawan-stack/issues/488はすでに閉じられているようです。

これは大きな問題です。 これを置き換えるために、上記の1つまたは2つの新しい問題を提出して、閉じることができますか？