8

次の (一般的な) シナリオを考えてみましょう。まず、OAuth を使用して、(素晴らしい) Web API がどのように見えるべきかを理解する方法を指定しようとします。フローが間違っている場合は、修正してください。

My API : 注目の的です。すべてのクライアントがこれを使用します。

My Web App : 他のクライアントと同じように API を使用します。

My Mobile App : Web アプリとまったく同じ方法で API も使用します。ユーザーはブラウザを開かなくても認証できる必要があります。

サード パーティの Web アプリ: API も使用しますが、ユーザー/リソース所有者は、アプリが何かを行うためのアクセス許可を付与する必要があります。彼らは、私のサイトにリダイレクトする (またはサイトへのポップアップを開く) ことによってこれを行い、必要に応じてユーザーをログインさせ、ユーザーにアクセスを要求します。

サード パーティのモバイル アプリ: サード パーティの Web アプリと同じ要件。


質問)

  • API は認証と承認を処理する必要がありますか?
  • API は、誰 (クライアント アプリケーションを使用しているリソース所有者) が API を使用しているかをどのように認識しますか?
  • ユーザーが私の公式クライアントを使用している場合、明らかにパーミッションを付与する必要はありません。私のクライアントはすべてのパーミッションを持っている必要があります。API を呼び出すときに、公式クライアントとサードパーティ クライアントをどのように区別すればよいですか?

これが私が理解していることであり、これまでに行うことです。これは、私が本当に助けを必要としているところです - これを正しく行うことです。

公式Webアプリ

- Client attempts to `GET /api/tasks/".
- API says "who are you? (HTTP 401)
- Official web app redirects to login form.
> Bob enters his credentials.
- .. now what? Get an authentication token? Cookie?
  • Web アプリは API のコンシューマーにすぎないため、ログイン状態をどのように管理すればよいでしょうか? Web アプリでそれを行う必要がありますか?
  • API に対して資格情報を検証する代わりに、Web アプリがユーザー データベースに直接アクセスできるようにする必要がありますか?

私は主に .NET (C#) を使用していますが、たとえば Node JS ベースの API にも適用できるアプローチが欲しいです。

これについてどう思いますか?特にクライアントフローは私にとって問題です。私が尋ねる理由は、絶対に必要な場合を除き、独自のセキュリティ ソリューションを展開するべきではないことを読んだためです。そのための標準的なガイドラインがあれば、お知らせください。:)

4

2 に答える 2

0

長くなりましたが、最終的に何をしたかを記録しようと思いました。

DotNetOpenAuth を使用しています。クライアントを含むデータベースがあり、Trustedフィールドがあります。これが設定されている場合、クライアントはパスワード許可を使用できます。これにより、そのクライアントに事前定義されたすべてのスコープが自動的に許可されます。

ファースト パーティの Web アプリはプレーンな Cookie 認証を使用します。JS でクライアント資格情報を公開するのはリスクが高すぎます。

于 2015-08-19T07:47:19.480 に答える