2

OAuth がうまく適合するかどうかわからない設計を検討していますが、これは基本的な問題です。

さまざまなレベルのセキュリティを必要とする企業の Web サービスがあります。

  1. ユーザーの成績を確認する - ユーザー名とパスワードが必要です
  2. ユーザーのグレードを変更 - ユーザー名/パスワード/RSA トークン番号が必要

したがって、アプリケーションが(1)を実行したい場合、資格情報を要求しますが、ユーザーがアクセスしようとしているサービスをOAuthサーバーに通知し、正しいフィールドが次のように表示されるようにしたいと思います.これが最初のログインです。

2 回目は、アプリケーション (ブラウザーまたはアプリ) にトークンがありますが、そのトークンは十分ではありませんが、セキュリティ要件はセキュリティ担当者の決定に基づいて変更される可能性があるため、アプリケーションはこれを認識すべきではありません。適切です。

そのため、(2) に到達するためにトークンが提示されると、それでは不十分であると判断され、エラーが返されるため、アプリケーションは新しいトークンの取得を試みることができます。

私はまだこれを実装していませんが、基本的な設計として、OAuth が私がやりたいことに適しているかどうか、または独自の認証システムを作成する方がよいかどうかはわかりません。

最初は、Web サービスのクライアントはモバイル Web アプリになりますが、ネイティブの電話アプリを作成するときに同じシステムを使用できるように、十分な柔軟性を持たせたいと考えています。したがって、問題のあるセキュリティをアプリケーションに認識させる必要があり、毎回資格情報を Web サービスに渡すのは満足できないので、使用できる暗号化されたトークンが必要であり、要件を満たしている場合(2) の場合、同じトークンで (1) に入ることができます。

では、OAuth はこれに適しているでしょうか?

これに基づいて、OAuth には認証の側面があるようです ( https://developers.google.com/accounts/docs/OAuth2InstalledApp )。

更新: - これには Open Connect ( http://openid.net/connect/ ) の方が OAuth よりも優れているようですが、現在 Open Connect について学んでいます。

4

1 に答える 1

1

私の意見では、oAuth を使用する利点は 2 つあります...

  1. ユーザーは、サービスの新しいユーザー名/パスワードを作成する必要はありません。
  2. パスワードを保存したり、ログイン用の ssl 証明書を持ったりする必要はありません (おそらく、他の目的で ssl が必要になるかもしれません)。

あなたは2つのサービスを持っていると言います。ユーザーが両方にログインする必要はないので、単一のコールバック URL を構成する必要があるため、ユーザーが (oAuth を使用して) ログインするファサード (Web サービス) を作成することをお勧めします。そのファサード サービスから、特定の呼び出しを承認し、これらの呼び出しを他のサービスに転送できます。

ユーザーKosが何を意味するのかはわかりませんが、oAuth は認証用であり、アプリでの承認用ではありません (私の考えでは)。アクセス権とともに、そのユーザーの内部表現を使用して oAuth ユーザーをマップする必要があります。これは、ユーザーを自分の側のどこかに保存する必要があることを意味します。唯一のことは、パスワードを保存する必要がなく、カスタム ログイン ページを開発する必要がないことです。

要するに、oAuth は、特定のユーザーが既知であり、認証されていることだけを伝えることができます。後は君しだい。oAuth の実装はそれほど難しくありませんが、簡単でもありません。したがって、これにより、先ほど述べた 2 つの利点に戻ります。このルートを使用するかどうか、およびその理由を決定する必要があります。

于 2012-07-05T14:03:52.203 に答える