6

私は、人々がユーザーとしてサインオンし、潜在的に複数のグループに属する Web サイトを設計しています。グループにはいくつかの異なるタイプがあります。私は、人々が直接使用できる Web サイトと、他の Web サイトで使用できる API を公開したいと考えていました。

サイト自体の通常のユーザーだけでなく、API を使用する Web サイトがユーザーに代わってシームレスにアカウントを作成し、ユーザーが自分のデータを両方から表示できるようにするログイン システムを実装する最良の方法は何ですか? Web サイトと API を使用する Web サイト

私は Django 1.5 を使用しているので、ユーザー モデルなどをカスタマイズしたいと思っています。API は Tastypie を使用して提供されます。

編集: 正直なところ、私の主な問題は、API キーがいつ役立つのか、また、API キーが (存在する場合) 通常のユーザー ログインとどのように共存するのかをよく理解していないことです。

4

3 に答える 3

11

使用事例：

API キーの最初の使用例は自動化です。あなたのapi key（または一般的に呼ばれるtoken）をサードパーティに提供すると、出来上がり、サードパーティにあなたのために何かをしてもらうことができます。サードパーティを信頼しなくなった場合は、サードパーティを取り消すapi keyか、再生成するだけです。API キーを使用すると、ユーザーは従来の認証 (例: username/password) を介してトークンを要求することで一連のアクションを開始および認証でき、ユーザーはそれを関係者に渡します。最後の電話番号に関する私の小さな話を参照してください。

なぜパスワードを使用しないのですか?

他の Web サイトのユーザーを危険にさらしたり、API を使用するためにパスワードを入力させたりしたくないためです。サードパーティが侵害された場合、ユーザーの通信またはパスワードが侵害されます。

良いリソースは次のとおりです。

Tastypie の API キー

ここに良い出発点があります：

from django.contrib.auth.models import User
from django.db import models
from tastypie.models import create_api_key
models.signals.post_save.connect(create_api_key, sender=User)

post_saveこれにより、シグナルのおかげで API キーが作成されます。2番目の部分は、ユースケースに合わせて認証用の複数のスキームを許可することですMultiAuthentication。

from django.contrib.auth.models import User
from tastypie.authentication import BasicAuthentication, ApiKeyAuthentication, MultiAuthentication
from tastypie.authorization import DjangoAuthorization
from tastypie.resources import ModelResource

class UserResource(ModelResource):
    class Meta:
        queryset = User.objects.all()
        resource_name = 'auth/user'
        excludes = ['email', 'password', 'is_superuser']

        authentication = MultiAuthentication(BasicAuthentication(), ApiKeyAuthentication())
        authorization = DjangoAuthorization()

その他の考慮事項

これらは、ネットワーク上で機密データを漏らさないための良い習慣です。

  • sslまたはなしでユーザー/パスワード認証を行わないでくださいtls。
  • sslまたはなしで http 基本認証を使用しないでtlsください。
  • を使用して、ユーザーがアクセスしてはならないリソースをロックダウンしますpermissions。
  • cache-control応答のヘッダーが正しいことを確認してください
  • ユーザーがトークン/APIキーをリセット/再生成/削除できるように常に許可します。
  • ユーザーは API キーを 1 つだけ持つ必要はなく、複数持つことができます。サードパーティごとに 1 つ。

私は gmail を使用しているので、 https ://security.google.com/settings/security (レビュー権限)の例を次に示します。ここでは、Google の openid がどのように使用されているかを確認できます。

Google openid の権限を取り消す

サードパーティごとに 1 つの API キーを使用する必要があるのはなぜですか? ユーザーが複数の api キーを持ち、特定の用途のためにそれらにラベルを付けることを許可する必要があるのはなぜですか? と同じです。.

答えは、api keyが と同じように共有するものである場合phone numberですが、すべての友達に同じ電話番号を与える必要はないということです (Google 音声 FTW!)。

  • ケース 1: 1 つの電話番号。

あなたの友人が行儀が悪く、たくさんの営業担当者にそれを渡した場合、あなたはかなりイライラするでしょう. あなたの電話が同じである場合、それを持っている人は誰でも、知らないうちに他の人と共有する可能性があります. 最終結果、すべての営業担当者はあなたの番号を知っています...あまり良くありません。でも、お母さんに電話してもらいたいですよね？したがって、実際に番号を変更することはできません。もっと危険な状況を想像してみてください。あなたは地元のピッツェリアにタブがあり、彼らは名前/電話番号であなたを知っています. 誰かがあなたの API キーを取得すると、あなたになりすましてピザを注文し、料金を請求する可能性があります (タブがあります!)。

  • ケース 2: 複数の電話番号:

100 の番号を 100 人の友人に与えると、彼らはあなたに連絡できるだけでなく、営業担当者が特定の番号であなたに電話をかけた場合、どの友人がその番号を譲渡したかを知ることができ、その 1 つの番号をカットすることができます。 . お母さんは、ブランチの行き先を教えてくれるので、今は幸せです。あなたの友人はピザを注文することにしました...あなたはそれをあなたの友人にたどることができます（またはあなたの友人の誰も知らないピザ屋に番号を提供する必要があります）.

于 2013-07-14T22:04:35.293 に答える
0

セキュリティの観点から、「API キー」には 2 つの主なクラスがあり、それぞれに異なる目的があります。

  • パスワードとユーザー名を組み合わせたようなものとして機能するランダムな API キー: クライアント構成ファイルに組み込まれており、シークレットと見なされます。このキーを所有するだけで、API アクセスが可能になります。キーはクライアントを識別する秘密を表すため (したがって、信頼を検証するため)、すべての要求で秘密を送信する必要があります。シークレットが傍受されないようにするには、接続を信頼する必要があります。つまり、すべての API アクセスで TLS/SSL を要求する必要があります。多くの場合、このアプローチは最初のリクエストでのみキーを使用することで拡張され、残りの接続はクライアントの IP アドレスにリンクされたローテーション セッション キーを使用して実行されます (Web サイトへのログインによく似ています)。
  • 非対称署名方式: DSA や RSA などの非対称暗号を使用して、クライアントの構成に格納される秘密鍵を作成します。シークレットはネットワーク上で共有されることはなく、代わりに各 API リクエストのハッシュが暗号化されます。サーバーは、各要求のハッシュ署名を復号化する各秘密鍵にリンクされた公開鍵を保持し、検証する要求の独自のハッシュを作成します。これは、TLS/SSL を必要とせず、セッション管理ポリシーを必要としないため、API 認証を実行するための推奨される理想的な方法です。

私は django の API 認証ライブラリを認識していません。優れた実装については、Amazon AWS の HMAC 非対称署名ベースのアプローチのソース コードを参照することをお勧めします。

于 2013-07-16T19:53:57.713 に答える