3

注: このトピックに関する StackOverflow の質問が他にもたくさんあることは知っています。私はそれらの多くを読んだだけでなく、他の多くのウェブサイトも読みました。私はまだ次の質問があります。

それで、私は新しい製品用の REST API を構築しています。現時点では、API は完全に私たちの Web サイトと電話アプリによる個人的な使用のみを目的としています。しかし、将来公開できるように API を設計するのが賢明かもしれないと考えています。

認証

OAuth を見てきましたが、SSL 経由の HTTP 基本認証は、私たちの API にとって十分に安全だと思います。私が理解していることから、SSL を介した HTTP 基本認証は、REST API を認証するための完全に実行可能な方法です。また、API 開発が初めての私にとっては非常にシンプルで魅力的です。

認可

ユーザーがユーザー名とパスワードを使用して API にログインすると、API の特定の部分へのアクセスのみが許可されます。つまり、自分のコンテンツにはアクセスできますが、他のユーザーのコンテンツにはアクセスできません。さらに、全員ができることは限られているかもしれません。

ユーザー アカウントに加えて、よりグローバルな管理タスク用に他の (ユーザー以外の) アカウントも用意する予定です。これらのアカウントは、API への完全なアクセス権を持つ可能性があります。

これは良いデザインですか？または、この方法でユーザーを認証するのは悪いことですか? この方法でクライアント (つまりアプリ) のみを認証する必要がありますか?

セッション

私の大きな疑問は、ユーザーが Web アプリにログインするときに、ユーザーのセッションをどのように管理すればよいかということです。REST では、リクエストごとにユーザー名とパスワードを送信することが規定されています。さらに、REST API はステートレスであるため、そこでセッションを管理することはできません。ただし、何らかの方法で Web アプリにログインしたことを追跡する必要があります。リクエストごとに手動でログインできないことは明らかです。

1 つのアプローチは、ユーザーがログインした後、ログイン資格情報 (電子メールとパスワード) を PHP セッションに保存することです。その後、API への後続の各リクエストで、それらの資格情報を使用できます。ただし、PHP セッションでユーザー名とパスワードを保存することは、間違っていると感じ、非常に安全ではありません。しかし、この方法で行われなければ、REST API と対話するときにセッションをどのように管理しているのでしょうか?

ユーザーのログイン資格情報をキーチェーンに保存できるため、電話アプリの方が簡単です。

設計に関する質問を手伝ってくれる人はいますか?

4

1 に答える 1

2

この質問は少し古いもので、すでに作業を終えているかもしれませんが、いくつかのヒントを提供したいと思います。たぶん、これらは将来あなたや誰かを助けるかもしれません. :)

認証

SSL を介した HTTP Basic Auth は非常に単純ですが、それは本当ですが、思っているほど安全ではありません。クライアントに「偽の」SSL証明書を1つインストールするだけで、中間者攻撃でトラフィックを盗聴できます.

偽の証明書をインストールするには? ブラウザではそれほど難しくありません。多くのユーザーは、巨大な赤い警告画面が表示されたときに [OK] をクリックするだけです。たとえば携帯電話の場合: http://cryptopath.wordpress.com/2010/01/29/iphone-certificate-flaws/

このソリューションを使用すると、トラフィックを 1 回傍受するだけで、ユーザーのパスワードを取得できます!

ヒント: ログイン時に一時パスワードを生成し、他のすべてのリクエストでこれを使用します。そのため、攻撃者はパスワードのログイン プロセスを傍受する必要があり、たとえばこのパスを電話でローカルに保存すると、はるかに困難になります。（もちろん、有効期限を追加することもできます...）

認可

私はあなたが何をするのかよくわかりません。ユーザー アクセス管理は良いことですが、プロジェクトによって異なります。

セッション

REST API だけでなく、HTTP の世界全体がステートレスです。PHP セッションを使用すると、セッション ID がクライアント側の Cookie に保存され、ブラウザはこの Cookie 値を毎回サーバーに送信します。

ユーザーは毎回ログインする必要はありません。彼らは一度ログインし、トークン/一時パスワードなどを取得します...そして（またはこれらのものを使用しない場合）、リクエストごとに基本認証ヘッダーを送信します。このようにして、誰がリクエストを送信したかを簡単に追跡できます。これは、既にそのユーザーが誰であり、サーバー上のデータを保存してリンクできるためです。

ユーザーに対処する方法はたくさんあります。基本認証はその 1 つです。そして、これを確認してください：RESTのOAuthのトーク​​ンとセッション 「OAuthトークンは明示的にセッション識別子です...」

ユーザーのパスワードと電子メールを保存する必要はありません。すべてのリクエストでクライアントからヘッダー/クッキーなどを確認するだけです。

ユーザーのログイン資格情報をキーチェーンに保存できるため、電話アプリの方が簡単です。

可能ですが、ユーザーの実際のパスワードを電話に保存することは非常に悪い習慣です。期間限定のトークンを保存する方が少し良いです。:)

他のすべての言語では、必要に応じて値を保存できます。たとえば、API に Python クライアントを使用する場合: トークンまたは必要なものを認証して変数に保存し、他のすべての要求でこの保存されたデータを使用します。

もう1つの補足：

ただし、PHP セッションでユーザー名とパスワードを保存することは、間違っていると感じ、非常に安全ではありません。

確かに安全ではありませんが、(実際の) PHP セッションはサーバー側に保存され、前述のように、クライアント側には単一のセッション ID のみが保存されます。このセッション ID を取得できる人は誰でも、特定のユーザーになりすますことができます。（IPチェック等の対策はありますが…）

于 2014-08-21T09:21:51.807 に答える