私は現在、Google Summer of Code プロジェクトの一環として、phpBB の API を開発しています。API のポイントは、開発者が phpBB ボードに接続するアプリケーションを作成できるようにすることです。
ユーザーには適切な認証方法が必要であり (ユーザーにユーザー名とパスワードをアプリケーションに直接入力させるのは明らかに悪い考えです)、私はこれを行うための複数の方法を検討してきました。
私はすでに独自の実装を行っていますが、話をした人は、むしろ OAuth を使用するべきだと言っています。OAuth について 1 週間ほど調べてみましたが、この場合にどのように使用すればよいか完全にはわかりません。Three-legged OAuth から私が収集したことは、アプリケーション開発者は、クライアント トークンを取得する前に、コンシューマー トークンを受け取るためにアプリケーションをサービスに登録する必要があるということです。開発者は自分のアプリケーションをすべての phpBB ボードに実際に登録することはできないため、これは実際には不可能です。
アプリケーションが自動的にサーバーからコンシューマー トークンを取得し、次にクライアント トークンを取得するかどうかについて考えていましたが、それは 3 脚の OAuth のポイントを無効にしているように思えます。
Two-Legged OAuth について少し読んだことがありますが、私が収集したところによると、それを認証として使用することは想定されておらず、内部アプリケーションのためのものですか??
これまでに実装した認証システムは次のようなものです。
- アプリケーションは phpBB ボードから認証トークンと署名トークンを要求します
- ユーザーは、トークンをパラメーターとして使用して、phpBB ボードの認証ページにアクセスするように求められます。
- アプリケーションは、トークンが有効かどうかを phpBB ボードで検証します。ユーザーは、ブラウザで認証フェーズを通過した後、アプリケーションにこれを行うように指示する必要があります。
- リクエストを実行するとき、たとえば
/api/forums/2/topics、アプリケーションは認証トークンとシリアルをリクエストに追加します。/api/forums/2/topics?auth_token=token&serial=2ここで、シリアルは、リプレイ アタックを阻止するために増え続ける数字です。次に、アプリケーションは HMAC-SHA256 を使用してリクエストをハッシュし、それを別の GET パラメータとしてリクエストに追加します。サーバーは同じハッシュを行って、それが正しいかどうかを確認します。このようにして、攻撃者は、最初の交換で署名トークンを手に入れない限り、リクエストを偽造できません。
OAuthについて学びながら、これの代わりにOAuthを実装しようとするべきかどうかを考えています。簡単に言うと、開発者が各サービスに登録することなく、複数のサービスにまたがる OAuth はどのように機能するのでしょうか?