OAuth 2ファーストパーティのモバイルアプリとシングルページアプリのパスワード

Question

私はファーストパーティのモバイルアプリとシングルページのウェブアプリの両方を持つプロジェクトを行っています。私はOAuth 2を認証に使用したいと思っていますが、これらのパブリックファーストパーティクライアントがクライアント資格情報を保護できないことを考慮して、この許可タイプを使用することをお勧めします。

理想的には私は認可コードグラントタイプの認証のために別のWebページへの外部ブラウザやWebアプリケーションのユーザーにモバイルユーザーをプッシュする必要はありません。

これらのクライアントタイプでパスワード許可タイプの作業を行うことはできますか、またはファーストパーティアプリケーションのOAuthの代替方法を検討する必要がありますか？

Answer 1

一般的に、データの安全性を確保する方法があるため、モバイルアプリではこれが簡単になります。たとえば、IOSの場合、秘密を保存できるキーチェーンがあります。モバイルアプリは、コードのどこかに置いておかない限り、クライアントの秘密を安全に保つことが大切です。

ただし、SPAに関する限り、何かを安全に保つ方法を見つけることは非常に疑問です。私は何度もやった

はのOAuth2の複雑さに対処し、そこClientSecretを保った非常にシンプルなAPIを構築することでした。 SPAはこのAPIを呼び出し、このAPIは要求をOAuth2保護された実際のAPIに渡し、応答をSPAに返信します。基本的に1つの余分なレイヤーが中間にあります。

明らかに、このレイヤーを追加すると、フロントエンドアプリケーションに別のレイヤーの保護が必要になることも明らかです。ユーザー管理があり、ユーザーが何かにアクセスする前にログインすることを期待している場合は、これが実行されます。もちろん、あなたのユーザー管理とOAuth2コンポーネントには違いがあります。 OAuth2は、認証されたアプリケーションだけがそのデータにアクセスできることを保証し、ユーザーが認証されるとすべてが良好であることを確かめることができます。

これがすべてでClientSecretを露出させずに不正誰ものOAuth2 APIをヒットしていないことを確認することの世話をします。 「信頼できる」アプリケーションについては

Answer 2

、すなわちあなたが「ファーストパーティ」アプリケーションを言うように、それは、モバイルアプリケーションのためのリソース所有者のパスワードのグラントで行くことに通常大丈夫です。アクセストークンとリフレッシュトークンのユーザー名とパスワードを交換し、モバイルアプリケーションにできるだけ安全に保存します。終了後、エンドユーザーのユーザー名とパスワードをメモリから消去することを忘れないでください。

シングルページアプリケーションの場合、フローへの移行は暗黙的なグラントで、フラグメント（#access_token=...）のリダイレクトを経由してアクセストークンを受け取るので、そこからSPAが取得できます。この場合、SPAはそれ自身のスコープ内でユーザ名とパスワードを決して使用することはありません。これらは、認可サーバーおよび/またはIDプロバイダのログイン・インタフェースにのみ公開されます（実装に応じて）。

SPAの場合、最初の認証と認可のために認可サーバーへの最初のリダイレクトがまだあります。アクセストークンをリフレッシュする必要がある場合は、OIDC仕様を調べることができます。この場合、追加の&prompt=noneが追加され、暗黙的な認可によって新しいアクセストークンを取得できるようになります。 a iframeです。最後に、この方法は、エンドユーザのユーザエージェント（=ブラウザ）とのセッションを持つ認証サーバに依存しますが、ではなく、でSPAの起点となります。