既存のレガシーWebアプリを移行してOAuth2を使用する方法

私は現在、自家製の承認と認証システムを使用して、100万人近くのユーザーがいる15歳のレガシーモノリシックWebアプリケーションを持っています。ハッシュアルゴリズムなど）。

今後12〜18か月間、主にUIに重点を置いてアプリケーションのオーバーホールを行いますが、基盤となるパーツもゆっくりとアップグレードします（Spring、Spring Securityなどへのアップグレード）。このプロジェクトでは、モジュールごとにUIのアップグレードに取り組むことにしました。各モジュールが完成したら利用可能にする。モノリスを個々のWebアプリに分割する絶好の機会（すべて同じUXデザインを維持）。

これを計画しようとして私が行き詰まっているのは、認証と承認のレベルです。すべてのモジュールにまたがるクロスカッティングソリューションが必要です。これにより、ユーザーがあるWebアプリケーションから別のWebアプリケーションに誘導されたときに、シームレスな移行が実現します。ユーザーは異なるWebアプリケーション上にいることさえわかりません。OAuth2は完璧なソリューションのように聞こえます。

これを統合する方法を理解しようとするのに行き詰まっています。独自のカスタムOAuth2サーバーを構築する必要がありますか？それはひどい考えのように私を襲います。しかし、どうやって私は：

1. すべてのユーザーアカウントと承認プロセスをサードパーティのOAuth2サーバーに移行する
2. アプリケーションの残りの部分と一致するようにルックアンドフィールをカスタマイズします（これがどれほど簡単に/可能性が高いかわかりません）
3. サードパーティのサーバーを介して接続するときに、一般的な「アプリケーションXYZがアカウントへのアクセス許可を求めています...」ポップアップを防止しますか？（例：Google OpenID、Facebookなど）。

私の目標は、ユーザーに現在の状態から新しい状態へのシームレスな移行を提供することですが、Webアプリケーションの外部ですべて認証および承認する個別のWebアプリケーションを作成する機能を提供することです。

開示：私はAuth0のエンジニアです。

それは1つの主要なポイントに依存します...次の場合に決定する必要があります。

1. 独自のIDプロバイダーと承認サーバーの構築や保守にかなりの時間を直接費やしたい（そして間接的にお金を費やしたい）
2. または、直接お金を使い、Auth0のようなサードパーティの認証プロバイダーを使用することを好みます。

両方のオプションは、機能要件の観点から完全に実行可能です。カスタム開発では、サポートすることに決めた機能を完全に制御できるので、回答の一部を、リストした要件にAuth0がどのように応答できるかに焦点を当てます。

ただし、それに入る前に、決定に関係なく、認証ではOAuth2ではなくOpenID Connectに焦点を当てる必要があります。モノリスを別々のWebアプリケーションに分割するだけでなく、APIも混在させることを計画している場合は、後者がより適切です。

既存のユーザーをAuth0ベースのシステムに移行する方法は？

データベースの使用を継続し、Auth0に依存して、使用する必要がある認証関連プロトコルへのすべてのコンプライアンスを提供するか、ユーザーをAuth0管理対象データベースに移行して、パスワードを保存および検証する方法について心配する必要をなくすことができます。

データベースを引き続き使用する場合は、「カスタムデータベースを使用してユーザー名とパスワードでユーザーを認証する」を参照してください

アプリケーションは認証のためにユーザーデータベースに依存することがよくあります。Auth0を使用すると、これらのリポジトリに簡単に接続し、それらをIDプロバイダーとして使用しながら、ユーザーの資格情報を保持し、多くの追加機能を提供できます。

_{（ドキュメントでは、例としてMySQLを参照していますが、他のデータベースエンジンもサポートされています）}

一方、Auth0へのユーザーの移行で説明されている移行プロセスを活用することで、ユーザー認証情報をAuth0データベースにシームレスに移動できます。

Auth0は、カスタムデータベース接続からAuth0へのユーザーの自動移行をサポートしています。この機能は、ユーザーがログインするたびに一度に1つずつAuth0データベースにユーザーを追加し、ユーザーにすべてのパスワードを同時にリセットするように求めることを回避します。

すべてのユーザーが一度にパスワードハッシュアルゴリズムの使用を開始することを希望する場合は、Management APIを介してAuth0ですべてのユーザーを作成することもできます。これには、ユーザーにパスワードのリセットを要求するという副作用があります。

カスタムの2段階認証（確認用の質問）を使い続けるには？

Auth0が提供する認証パイプラインは、ルールを使用して完全にカスタマイズできます。つまり、プロトコルに関連するものを実装する必要はありませんでしたが、アプリケーションで認証がどのように行われるかを細かく調整することができます。

これには、ユーザーがAuth0によって検証された初期パスワードを提供し、カスタムルールから詳細情報を要求する2段階認証プロセスを実行する方法として、既存の検証質問を引き続き使用する可能性が含まれます。（ルールは単なるJavaScriptなので、可能性は無限です）

ただし、検証の質問を破棄し、代わりに認証プロセスのセキュリティを強化する方法としてAuth0 Guardianを使用することもできます。

認証UIのルックアンドフィールをカスタマイズする方法は？

Auth0を使用すると、デフォルトのログインページやLockなどの認証ウィジェットを活用して、クリーンな認証UIをすぐに利用できます。これらはすべてある程度のカスタマイズをサポートしており、いつでも独自のUIを自分で作成する代わりに、ユーザーインターフェイスに制約を課さない低レベルのAuth0ライブラリ（Auth0.js）を利用できます。

カスタマイズの詳細については：

• ロック10のルックアンドフィールのカスタマイズ
• ホストされたページをカスタマイズする方法

明示的な同意ページを防ぐ方法は？

Auth0は、認証用のIDプロバイダーとしても、APIのOAuth2承認サーバー（現在は米国リージョンでのみ利用可能）としても使用できます。

IDプロバイダーとして、同意ページについて心配する必要はありません。ユーザーは、Auth0によって管理される資格情報で認証され、アプリケーションにリダイレクトされます-それだけです。

OAuth2 as a serviceシナリオでは、同意が有効になっている場合、ロードマップには、特定のアプリケーションの同意ページのバイパスを許可することが含まれます。

最後に、それはあなたがそこにたどり着いた非常に興味深く、挑戦的なプロジェクトのように思えるので、あなたの最終的な決定とは無関係に幸運を祈ります。

レガシーアプリケーションの認証システムを再実装する必要があったとき、私は以前の仕事で同様のことをすでに経験しました。私たちは独自のIDプロバイダーと承認サーバーを実装しましたが、正直に言うと、本当に必要なものを忘れたのではないかと感じています。

それはあなた自身のセキュリティを展開する上での最大の問題だと思います、締め切りがショートカットを課し、セキュリティが本当にショートカットを作るのに良い領域ではない場合があるでしょう。

他にご不明な点がありましたら、お役に立てると思われる場合はお知らせください。