0

私は自分の問題 (こことここ)についてさまざまな質問をしました。また、IRC の #oauth & #openid freenode のチャネルでも質問しました。（これは「UP」の質問であり、別の問題です）

私のプロジェクト構成を要約します: 誰でも私の API を使用できるアプリを作成する可能性があります。まず、API と Web ベースのアプリに取り組みますが、API に関するドキュメントは公開されます。これは、Twitter API に少し似ています。

私が直面している問題は、どのユーザーが API を使用しているか (ツイートなどの個人データを取得するため) をどのように確認できるかということです。周りのすべてのアプリ）。

私はよくグーグルで検索し、以前の回答の助けを借りて、OAuth を調べました。

OAuthの仕組みを理解している限り、ここでどのように：

  • ユーザーが自分の API (ウェブ、モバイルなど) を使用するアプリにアクセスします。
  • アプリは、認証 (ここでは OpenId を使用します) と承認 (OAuth) のためにユーザーを API にリダイレクトします。API にはログインと承認用の Web インターフェイスがあるため、これは少し奇妙です (Twitterがそうしているので、これがどのように機能するかを推測します) 。
  • API は、いくつかのトークンを使用して、接続されたユーザーをアプリにリダイレクトします。これらのトークンには、現在アプリを使用しているユーザーを API に示すために、アプリが保存する必要があるユーザーを表すトークンがあります (私は正しいですか?)

これまでのところ、すべてがうまくいっています。しかし、私が理解できないのは、ユーザーがアプリを終了して再び行ったときです。アプリは、ユーザーが以前に使用したユーザーであることをどのように記憶できますか?

( Cookieの回答を私に提示する前に、これは単純な例であることに注意してください。ユーザーが Cookie をクリアしたり、コンピューターをフォーマットしたり、コンピューターを変更したりしても同じです。)

私が見つけることができる唯一の解決策は、認証されていないユーザー (たとえば、Cookie を記憶していない) がアプリにアクセスしたときに、アプリが彼を API に再度リダイレクトして自分自身を認証することですが、今回はユーザーが再認証する必要はありません。アプリは既に許可されているため、許可 (承認) します。その後、API はユーザーをアプリに戻し、ユーザーがこれで遊べるようにします。

これは適切で安全な方法ですか？

#OAuth IRC チャネルは新しいプロトコル WebID について教えてくれましたが、これは現在ドラフト前のモードであり、将来的に継続的に変更されるものを使用したくありません :/

ご助力ありがとうございます！

4

2 に答える 2

1

簡単な答え: OAuth は認証済みアクセス トークンになります。そのアクセス トークンは 1 人のユーザーに関連付けられています。アクセストークンが有効である限り。3 番目のアプリケーションは、API がアクセス トークンに許可することは何でも実行できます。

長い答え: OAuth の問題は、ユーザーを「ログイン」させないことです。OAuth は、ユーザーがログインしているかどうかにかかわらず、ユーザーに代わってデータにアクセスするために使用できるアクセス トークンと呼ばれるものをサード パーティ アプリケーションに提供します。

多くのサービスでは、アクセス トークンが制限されています。たとえば、Twitter は、読み取り専用と読み取り/書き込みの 2 種類のアクセス トークンを発行します。しかし、API を使用するためにログインするという概念はありません。アクセス トークンが有効である間、サード パーティのアプリケーションはユーザーのデータにアクセスし、ユーザーの明示的な対話なしに変更を加えることができます。

ほとんどの API プロバイダーには、アクセス トークンを取り消す機能があります。これは、Twitter でConnections ページを見ると起こることです。アクセスの取り消しリンクを参照してください。 Twitter でアプリへのアクセスを取り消す

個人的には OAuth アプローチが気に入っています。API プロバイダーとして、アクセス トークンに許可する操作を制御でき、ユーザーは自分のリソースを使用して悪いアプリケーションを強制終了できます。認証に関する限り、OAuth は安全です。サードパーティのアプリケーションは、ユーザーのパスワードを取得しません。ただし、認証されると、API で許可されていることは何でも実行できます。

于 2010-12-31T01:04:12.183 に答える
1

Twitter がどのように機能するかを調べてみると、不足している点はプロジェクトの別のレイヤーにあると思います: 公式ウェブサイト:

代替テキスト

問題は、サード パーティ アプリケーションに Twitter の使用を許可する場合、このアプリケーションは、接続している場合は Twitter API の OAuth ページにリダイレクトしますが、接続していない場合はログイン ページにリダイレクトします。これはhttp://api.twitter.com/login にあります (twitter.com だけでなく、api.twitter.com に API を保持してユーザーをログに記録することが正しいかどうかはわかりませんが、これは単なるセマンティクスです) )

したがって、ワークフローは次のようになります。

  • ユーザーがサードパーティのアプリケーション (Web サイトなど) にアクセスする
  • このサード パーティは、ユーザーを認証用の API にリダイレクトします。
  • API は、最初に認証のためにユーザーを Web サイトにリダイレクトします
  • 公式 Web サイトは、ユーザーを OpenId プロバイダー (または Facebook 接続) にリダイレクトします。
  • 認証が行われます（複数のリクエストを介して）
  • Web サイトは、認証に成功した後、ユーザーを API にリダイレクトします。
  • ユーザーは、サードパーティのアプリから要求されたアクセス許可を許可/禁止します
  • API はサードパーティ アプリに戻ります。
  • ユーザーはアプリケーションを使用できる (または使用できない) ようになりました。

この実装には 2 つの問題があります。

  • ユーザーが認証されない (Cookie をクリアした、他のコンピューターから自分自身を接続したなど) たびに、公式 Web サイトにリダイレクトされ、次にサードパーティ アプリケーションにリダイレクトされることによって、認証方法を実行する必要があります (アプリケーションが自分のデータにアクセスすることを既に許可しているため、API は透過的です)。
  • これらすべてのレイヤーは、リダイレクトが多すぎるため、認証プロセスでユーザーを確実に失います。
  • 考えられる解決策は、たとえばモバイル アプリの場合、ユーザーの access_token を保存することですが、純粋な html/css/js 指向のアプリでは、これは不可能です。ユーザーをAPIのaccess_tokenに一致させるサードパーティWebアプリケーションのログイン/パスワードは、Seesmicのような別のソリューションになります（私は思う）が、これは役に立たない（私たちにとってはSeesmicではありません）：のアイデアユーザーのパスワードが無用にならないようにします。

これは可能な説明ですが、これがどのように可能であるか、およびその解決策についてのあなたの考えについて、より詳細な情報が必要です。それはうまくいくでしょうか？

（これは（不完全でよくわからないので、同意します）回答として追加しました。

于 2011-01-03T11:36:08.303 に答える