認証システムは、多くのWebサイトのバックボーンとなっています。 これにより、ユーザーはサイトにログインし、訪問のたびにデータを保持することができます。 これは、ユーザーが自分の詳細を提供することで報われる、堅牢なユーザー エクスペリエンスを提供する上で非常に重要です。 認証はしばしば個人的なプライベートデータへのアクセスを提供し、それが公開された場合、ユーザーに害を及ぼす可能性があります。 これらを防ぐために、認証プロトコルは、ユーザーがどのような環境からでも安全にシステムにログインできるようにしながら、リクエストを保護するために作成されました。 これは、Cookie、セッション識別子、およびログインページに依存する、より複雑なソリューションの代わりに、標準的な HTTP ヘッダを利用するものです。 基本的な認証システムには、ほとんどセキュリティが組み込まれていません。 認証情報はBase64エンコーディングで送信され、暗号化もハッシュ化もされません。

認証情報は、以下の形式にまとめられ、ヘッダーに含まれる必要があります。 http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth は基本 SSL 認証と似ていますが、パスワードが一方向ハッシュを使って暗号化される点が異なります。

Digest Auth リクエストの典型的なフローは以下の通りです。

1. ユーザが認証が必要なページに移動する。
2. サーバは 401 メッセージで応答し、ユーザが現在コンテンツにアクセスする権限がないことを意味する。 レスポンスには、リプレイ攻撃を防ぐために認証時に使用される nonce も含まれます。
3. 次にサイトは、必要な詳細 (ユーザー名とパスワード) を収集するために認証インターフェイスを表示します。
4. 提供された詳細は、応答コードを持つリクエストに含まれる認証ヘッダーでサーバーに再送信されます。
5. その後、サーバーは提供された認証情報を検証し、認証を受け入れるか、認証情報が不正な場合は 401 メッセージを返し、ユーザーは認証インターフェイスで再度プロンプトを表示されます。 https://www.ietf.org/rfc/rfc2617.txt

   OAuth 1.0

   OAuth 1.0 プロトコルは、サーバーとサイト間で共有される秘密に依存しています。 この共有秘密は、リクエストに含まれる署名を生成するために使用されます。 生成された署名は、サーバー側で認証要求の有効性を確認するために使用されます。

   1. サイトはRequest Tokenを取得する。
   2. ユーザーはRequest Tokenを承認する。
   3. サイトはRequest TokenをAccess Tokenに交換する。

   3-legged OAuth リクエストの完了プロセスは、一般に次のように処理されます。

   1. サイトは Request トークンの署名付きリクエストを送信します。 このリクエストには、次のパラメータが含まれている必要があります。

      1. oauth_consumer_key
      2. oauth_timestamp
      3. oauth_nonce
      4. oauth_signature
      5. oauth_signature_method
      6. oauth_version
      7. oauth_callback

      このリクエストはサーバーで検証され、検証されると次の形式でリクエスト トークンが返されます。

      1. oauth_token
      2. oauth_token_secret
      3. そしてサーバーから返される他の追加パラメータ。
      4. リクエスト トークンを取得した後の次のステップは、ユーザーにログイン認証情報を入力するよう促すことです。 これらは oauth_token リクエスト トークンで署名にフォーマットされ、検証のためにサーバーにリクエストで返されます。 このリクエストの認証に成功すると、サーバーは以下を返します:
      5. oauth_token
      6. oauth_verifier

      これらは次のステップでアクセストークンを取得するために使用されます

      1. 最後のステップは、ステップ2で取得した詳細情報と、サーバーリソースへのアクセス時に使用されるアクセストークンを交換します。 アクセストークンの交換は、以下の手順で行います。 以下の署名付きリクエスト
      2. oauth_token -ステップ2から返される
      3. oauth_consumer_key
      4. oauth_nonce
      5. oauth_signature
      6. oauth_signature_method
      7. oauth_version
      8. oauth_verifier -でサーバーに対してリクエストを行うことが可能です。手順2で返されたアクセストークン

      これは、サーバーから情報を要求するために、あなたの秘密と組み合わせて使用されるアクセストークンを返します。

      OAuth 1.0 プロトコルの詳細については、こちらを参照してください。 https://tools.ietf.org/html/rfc5849

      OAuth 2.0

      これは OAuth 1.0 プロトコルに似ており、リクエストをフォーマットするためにクライアント ID と秘密に依存しますが、OAuth 1.0 システムに固有の複雑な署名プロセスの多くを簡略化します。 3本足のOAuth 2.0を使用したユーザー認証の流れは、以下の通りです。

      1. User is directed to the service for authorization with the following details included in the authorization URL.このプロトコルを使用してユーザーを認証するプロセスは、次のとおりです。

         1. client_id
         2. redirect_uri
         3. response_type
         4. scope

      2. ユーザーはサービスで認証し、アプリケーションに自分の詳細へのアクセス権限を付与することができます。

         1. code
         2. state

      3. ステップ 2 で返されたコードは、アプリケーションがアクセストークンを要求するために使用されます。 このリクエストには、

         1. client_id
         2. client_secret
         3. code
         4. redirect_uri
         5. grant_type – これは “authorization_code”

      サーバがこれらの詳細を検証し、有効なら有効期間付きのアクセストークンを返送する、というものでなければなりません。 これらは通常、次の形式で返されます。

      1. access_token
      2. expires_in
      3. refresh_token

      なお、OAuth 2.0 プロトコルの詳細については、 こちらで確認することができます。 http://oauth.net/2/

      認証プロトコルにより、さまざまなセキュリティ レベルでデータを保護することができます。 アクセスされるデータと希望するセキュリティ レベルに応じて、上記のプロトコルのいずれかを実装すると、データが安全で、システムに許可されているユーザーによってのみアクセスされていることを確信することができます。