4

Web ページにトークン認証を実装するには、どの手順に従う必要がありますか?

要約やリンクは大歓迎です。

Facebook や Google と同じように、初めてクライアントがログインしてトークンを受け取り、それを次のアクションで使用したいと考えています。OAuth についても読みましたが、サードパーティからアプリケーションへのアクセスを許可したくありません。

長いお返事ありがとうございます。これについてもっと読む必要があることは明らかです。

私が知りたいのは、トークン認証を使用する基本的な Web アプリケーションを実装するための "手順" を知ることです。つまり、一度ユーザーがログに記録すると、コンテンツの追加、編集などのアクションを実行できます。

私が言っていることは、サーバーが HTML ヘッダーに SESSION_ID を追加し、後でリクエストが識別され、そのセッションに関連付けられるセッションに似ていることを知っています。セッションの方法はスケーリングに適していないことを読んだので、OAuth に移行する前に gmail や facebook などの同様のシステムを実装したいと考えています。おそらく、私は oauth に似たものについて話しているのでしょう (あまり深くは読んでいません) が、3 本足ではなく 2 本足です。

4

2 に答える 2

7

要件について考え、適切なプロトコルとそれを実装する適切なソフトウェアを選択する必要があります。

詳細がなければ、これ以上言うのは本当に難しいです。

  • 1 つまたは複数の Web アプリケーションの認証について話しているのですか? 異なる Web アプリケーション間でシングル サインオンが必要ですか?
  • すべてのユーザー データをサーバーに保存する必要がありますか、それともユーザーが Google アカウントなどでログインできるようにする必要がありますか?
  • トークンにユーザーに関する情報を含める必要がありますか?
  • アプリケーションはどのプラットフォームで開発されていますか?
  • どの認証方法を使用する必要がありますか?
  • ポータルを実現したいですか？

要件に適合する場合と適合しない場合がある、非常に幅広いプロトコルとツールがあります。

http://en.wikipedia.org/wiki/Category:Authentication_methods

http://en.wikipedia.org/wiki/Category:Identity_management_systems

個人的には、複数の Web アプリケーション間のトークン ベースの SSO にはCAS ( http://www.jasig.org/cas ) が好きです。Java ベースですが、PHP と .Net もサポートしています。

ユーザーが Google や Yahoo などの任意のアカウント (構成可能...) でログインできるようにし、ユーザー情報を自分で保存したくない場合は、OpenID で十分です。

Kerberos/SPNEGO は、企業のイントラネット アプリケーション用に windows-sso を統合したい場合に適した方法です。

大学のアプリケーションには、おそらく SAML/Shibboleth が最適です。大学以外ではあまり人気がありません。おそらく、かなり複雑なプロトコルであるためでしょう。

ああ、私はほとんど忘れています。ほとんどの Web フレームワーク/標準には、昔ながらの「フォームベース認証」の独自のバージョンがあります。ユーザーがログイン フォームに移動すると、ユーザー名とパスワードが入力されます。どちらも、Web/アプリケーション サーバーに転送される SSL を使用する場合と使用しない場合があります。サーバーは、ある種のデータベースに対してそれを検証し、ユーザーに Cookie を提供します。これは、ユーザーが要求を送信するたびに送信され、検証されます。しかし、これらすべての光沢のあるプロトコルに加えて、これはかなり退屈なようです:-)

また、Web 認証を使用する前に、Web セキュリティ全般について少し考えてみてください ( http://journal.paul.querna.org/articles/2010/04/11/internet-security-is-a-failure/ http://www.eff.org/files/DefconSSLiverse.pdf ) と、サイトをさらに悪化させないためにできること ( http://www.codinghorror.com/blog/2008/08/protecting-your -cookies-httponly.html http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf )。

于 2011-01-04T00:04:13.613 に答える
1

あなたのポイントを参照してください。

プロトコル レベルでは、非常に単純化されたトークン アプローチは HTTP 基本認証です。しかし、ログアウト機能がないなどの理由で、これが当てはまらないことがよくあります。

カスタムの単純な Cookie ベースのアプローチは、たとえば次のようになります。

  • サーバーはある種のシークレット (推測しにくい値) を生成します。
  • ユーザーが保護されたリソースにアクセスしようとすると、ログインフォームにリダイレクトされます
  • 認証が成功すると、彼は Cookie を取得します。この Cookie には、ユーザー名、タイムスタンプ、{username server-secret timestamp} のハッシュの 3 つの値が含まれています。
  • ユーザーが要求するたびに、サーバーはハッシュ値を再計算し、それをクライアントが Cookie で送信する値と比較します

(さらに考慮する必要があります: httponly とセキュア フラグ、トランスポート層のセキュリティ、リプレイ攻撃など)

Amazon S3 は認証トークンを HTTP ヘッダーに保存し、HMAC を使用して計算します。ここで説明されています: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?S3_Authentication.html (ブラウザーベースの Web アプリケーションでの使用は必ずしも推奨されません)

近くに REST に関する本がある場合は、認証に関する章があるかどうかを調べることができます。おそらく、物事はここよりもはるかにうまく説明されています:-)

この種の認証を実行できるフレームワークがいくつかあります。セキュリティ上の理由から、独自のものを実装する前に最初にそれらを確認することは理にかなっています.

于 2011-01-06T00:44:16.563 に答える