「パスワードのリセット」機能はどこにあるべきですか？
私たちは最近、APIを通過する非常に基本的な認証メカニズムから、認証サーバーとAPIサーバーの両方を持つようにモバイルアプリのバックエンドを見直し、認証サーバーがログインとこれらのトークンに基づいてAPI認証クライアント。アプリに接続されたモバイルデバイスのブラウザーを開きます。これにより、ユーザーは認証サーバーのWebインターフェイスに直接資格情報を入力でき、パスワードがアプリを通過する必要がなくなります。これは、潜在的なセキュリティリスクです。
また、「ユーザーの登録」機能と「パスワードの変更」機能のためにモバイルデバイスのブラウザーを開く同じメカニズムを使用するように切り替えました。どちらの場合も、これらはユーザーがパスワードを入力するタイミングであり、 tアプリを通過させたい。
ただし、「パスワードを忘れた」機能についてはわかりません。これは、ユーザーがパスワード（パスワードリセットリンクが送信される電子メールアドレスのみ）を入力する必要がないため、現時点ではアプリのUIを使用してAPIサーバーを通過しているため、パスワードは公開されません。アプリ、およびAPIと認証サーバーがユーザー認証情報データベースを共有しているため、APIはパスワードリセットリンクを生成してDBに保存できますが、この機能をWebインターフェースとしてではなく、認証サーバーで公開する必要があります。登録、ログイン、パスワード変更の方法を教えてください。もしそうなら、なぜですか？長所と短所は何ですか？
私の経験から、すべてのIDベースの操作を1か所で行うことが常に推奨されます。ユースケースでは、アイデンティティを管理するのはAuthNサービスです。
私はまた、この市場で最大のゲーマーであるGoogleアカウント、MS Azure AD、GitHub、Twitterを調査することをお勧めします。これらのIDプロバイダーを使用してユーザーを認証するアプリケーションがある場合、パスワードのリセット機能（およびその他）はIDプロバイダーで実行されます。私はそれは間違いではないと信じています。さらに、Ping、Auth0、KeyCloakなどのIDプロバイダーソリューションのプロバイダーも、このタスクに独自のサービスを提供しています。
同じことがあなたの場合にもあります。アプリに独自のIDプロバイダー（IdP）を提示しているため、同じIdPを使用している他のクライアントアプリを作成する可能性を考えている場合。そのアプリケーションに個別に「パスワードを忘れた」を実装しますか？私はあなたが自分自身を繰り返したくないと信じています。すべてのパスワードを忘れる機能のベストプラクティスを1か所に実装でき、他のアプリに煩わされることはありません。
まとめると、Auth Serverに実装することをお勧めします。
忘れたパスワード機能を実装する方法に根本的な問題は何もないと私は思います。
ただし、このプロセスは安全に実装する必要があります。そうでない場合、そのリンクのみを使用してアカウントを1回または複数回ハイジャックできます。
- 忘れたパスワードリンクは複数回機能しますか？;後で再利用できないようにしないでください。
- 忘れたパスワードのリンクには、推測できない一意の識別子が含まれていますか？推測できないようにする必要があります。
- パスワードがなんらかの方法でリセットされる前にリンクをたどると、ユーザーは追加の認証トークンの入力を求められますか？アカウントの所有権を確認する必要があります。
- 機能が要求されたときに、システムはすぐにパスワードをリセットしますか？ユーザーがユーザー名を知っているアカウントに対してDoSを防止するべきではありません。ユーザーが追加の認証トークンを提供してその正当性を確認するまで、パスワードに触れないでください。
認証プロバイダーも制御するかどうかによって、これらのすべての側面を制御できる場合とできない場合があります。