4

特にモバイルアプリケーションの場合、推奨されるRESTAPI認証/承認メカニズムに関してWeb上でさまざまなシグナルを受信して​​います。

  1. OAuth 1.0がありますが、それは必要以上に複雑であり、ネイティブクライアントをあまりサポートしていないと言われています（コールバックURLは非常にブラウザ中心です）。一方、それをサポートしている大手プロバイダーが1社あります（Twitter）。
  2. 次に、1.0よりも改善されていると思われるOAuth 2.0があり、デフォルトの呪文（ベアラートークンに置き換えられています）でクライアント側の暗号を取り除きますが、一部の人々はそれが設計によって壊れていると考えています、そしてベアラトークンはCookieに勝るものはありません。大ざっぱなプロバイダーからのSSL証明書は、モバイルクライアントをだまして、エンドポイントが信頼できる機関であると信じ込ませることができます。ただし、2つの主要プロバイダー（GoogleとFacebook）がサポートしています。
  3. そして、混乱全体を回避し、自分自身を転がすことを提唱する人々がいます。

それで、それはどれですか？

4

2 に答える 2

3

これは生け垣のように聞こえますが、答えは「アプリケーションに適したものは何でも」です。

OAuthやOpenIDなどのサードパーティの認証システムがその役割を果たしており、一部のアプリケーション、特にクライアントが個人の資格情報を別のサーバーシステムにフォークすることなくAPIユーザーになることができるような種類のシステムに最適です。

ただし、そのような制約や要件がないシステムを構築している可能性があり、サーバー上にアカウントを作成するようにクライアントに依頼するのが妥当な場合があります。その場合、HTTPSと基本認証を使用することで、おそらく劇的に物事を単純化することができます。クライアントにユーザー名/パスワードを適切なヘッダーで渡してもらい、接続がSSLで保護されていることを確認します。または、クライアントに資格情報に証明書を使用してもらいます。

まず、「セキュリティ」があなたにとって何を意味するのかを列挙し、ゼロから作業することをお勧めします。整合性の保証、否認防止、リプレイ保護、クライアントへの影響、パフォーマンス、APIの使いやすさなど、関連するすべての側面を考慮してください。そこから、必要なのがHTTPS /基本認証だけであるかどうか、またはAPIキー、OAuth、OpenID、チェックサムなども追加する必要があるかどうかを判断します。

于 2012-04-26T15:25:38.513 に答える
1

OAuth 2をお勧めしますが、クライアントで追加の証明書チェックを行います。証明書がVerisignからのものである場合は、他のCAからのすべての証明書を無効にします。ただし、更新を配布するのが好きでない限り、必ず同じCAで証明書を取得してください。

ただし、最終的には、サーバーへの接続が完全に安全であることを確認できるのはクライアントだけです。決してそれを忘れないで。

于 2012-04-26T15:37:13.683 に答える