web-dev-qa-db-ja.com

REST APIとスリムフレームワークの保護

私はREST APIにかなり慣れていないので、すでにかなりの数の質問が投稿されていることに気付きました。しかし、これらを熟読すると、実際にはこれを処理する方法についてさらに混乱しました。

REST API using Slim Framework を作成しました。これは単にデータの転送に使用しています。ユーザーログインや認証は使用しないので、安全であると信じています。これには、公開鍵と秘密鍵を使用するシステムが必要ですが、よくわかりません。

誰かがこれを行うための正しい/最も安全な方法、または素晴らしいチュートリアル/リソースについての洞察を持っている場合。どんな助けでも大歓迎です。

18
Drew

SSLを使用して、転送中のデータを暗号化できます。

しかし、SSLは単なる暗号化です。サーバー側のSSLは、クライアントの認証も承認も行いません。 承認は質問に答えると考えることができます発信者は彼が求めていることを行うことができますか?Authentication発信者のIDを確立するか、認証は通常、承認を行うために必要な最初のステップです。 「アイデンティティ全体」が必要ない場合もあります。特定の側面を確認するだけで済みます。たとえば、自動洗面所のゲートは、身元を確認するために、あなたが誰であるかであるかを知る必要はありませんが、男性または女性である場合に限ります。同様に、一部のサービスはあなたが誰であるかを気にしません。特定のネットワーク(IPホワイトリスト)から電話をかけている場合、または特別なトークンを持っている場合は、アクセスが許可されます。

サーバーが許可された呼び出しと許可されていない呼び出しを区別できるようにするには、いくつかのオプションがあります。

  • IPホワイトリスト。サービスを呼び出すアプリまたはエージェントのIPアドレスがわかっている場合は、サービスの実装でそれを指定できます。サービスは、着信要求のIPをチェックし、ホワイトリストにない要求を拒否できます。これは、発信者のアドレスに基づく一種の「暗黙の」承認です。

  • アプリが各呼び出しで提供する秘密のトークン。認証をしたくないとおっしゃいましたが、これは認証の一形態です。あなたはそれを「ベアラートークン」と呼ぶかもしれません。このトークンを持っている人は誰でも承認を得ます。サーバーでは、トークンの値を確認し、既知の値と一致しない呼び出しを拒否します。これは、トークンが明示的に渡され、ネットワークアドレスとは関係がないことを除いて、IPホワイトリストとほとんど同じように機能します。

  • トークンとキーのペア。これはユーザー名/パスワードに似ていますが、アプリの認証に使用できます。これを使用して、アプリ自体のIDを提供します。上記のようにサービス側で確認してください。

  • ユーザー名/パスワード。アプリのユーザーを認証します。

これらを組み合わせて、必要なソリューションを作成することをお勧めします。つまり、クライアントリクエストは、Iアドレスからのものである必要があり、「承認済み」と見なされるには、アプリのトークン/キーとユーザーのユーザー名/パスワードが必要です。

16
Cheeso