2

私が開発しているいくつかのアプリに最適なアーキテクチャを見つけようとしています。

どちらのアプリでも、google / twitter / LinkedIn/etcを使用してユーザーIDの認証を提供したいと思います。このアプリは、node.jsで書き込んでいるサーバーにデータを送信するオプションを備えたiOSアプリで構成されています。

OAuthまたはOpenIdのいずれかを利用して、上記のサーバーに対するユーザーの識別を処理し、独自の認証システムを導入する必要がないようにします。つまり、ユーザーがデータのアップロードを選択するときにIDを再利用できるようにします。

また、ユーザーを特定し、名前とメールアドレスを取得する以外に、現時点ではそのAPIを使用するつもりはないことにも注意してください。

私には2つの選択肢があると思います。

  1. 承認コードをiOSクライアントに配置し、サーバーが検証できるデータとともに、ある種のキーをサーバーに送信します。

  2. iOSクライアントをかなり馬鹿にして、ノードサーバーからの承認を処理します。

認証を一元化でき、Webサイトもサポートできることを意味するため、おそらく2番目のオプションをお勧めします。それが私の現在の理論です。

このようなことをした人は、長所と短所、OAuthまたはOpenId、またはいくつかの例へのリンクに関するいくつかのポインタを教えてもらえますか？

4

1 に答える 1

2

以前のアプリでは、2 つのアプローチの組み合わせを選択しました。これらのサービスで将来 API 呼び出しを行う必要がある場合に備えて、サーバー上のユーザー データを一元化したいと考えていました。また、クライアントのユーザーにネイティブの oAuth エクスペリエンスも必要でした。つまり、Android と iOS では、開発者はネイティブの Facebook アプリ (利用可能な場合) を介してシングル サインオン/承認を実行することができます。私の意見では、それはより良いユーザーエクスペリエンスです。また、Twitter の場合、oAuth プロセスでは、コールバックに PIN コードを入力する必要がある場合がありますが、これはおそらくクライアント側で処理する必要があります。

これらのサービスで追加の API 呼び出しを行う場合は、クライアントが取得したアクセス トークンをサーバーに渡して保存し、後で使用することができます。ただし、トークンが長期間有効であることが予想される場合 (つまり、FB でのオフライン アクセス許可) .

いずれにせよ、これは主にユーザー エクスペリエンスの決定です。

于 2012-06-06T16:21:17.907 に答える