#34-認定&承認2

3362 ワード
TIL authorization authentication テキストリンク

権限


ユーザがサーバにログインした後,そのユーザが正しいかどうかを確認するプロセスが承認である.
認証が必要な理由はHTTP特性です.

HTTP特性


  • リクエスト/レスポンス-リクエストとレスポンス

  • 無状態の性質-保存しない性質

    • ユーザーがログインしている場合、サーバはどのようにログインしていることを知っていますか?


    確認のためにヘッダーにメタデータを送ります.
    このメタ情報はJSON Web Token-別名JWTである.

    トークンのセキュリティを強化する方法


  • 発行されたトークンが特定のipでのみ使用可能であることを制限する

  • ブラウザの認証を使用して他のコンテンツを検証

  • あるいはロケをします.

  • 一度に認められたコインは使い捨てに制限されています

  • ログインごとにトークンが更新されます

    • JWT(JSON Web Tokens)


    ユーザーのログインに成功すると、 accesstokenという暗号化されたユーザ情報をrequestに送信します.
    // 유저 로그인:
POST /auth HTTP/1.1
Host: localhost:5000
Content-Type: application/json

{
    "username": "joe",
    "password": "pass"
}
    // access token:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E"
}
    その後、サーバは アクセスポイントを復号することによって、対応するユーザ情報が得られる.
    例えば
  • .
    access token ineyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E  復号化には、次の情報が得られます:
    • {
    user_id = 1 
}
    得られたプレイヤーIDを解読することで、そのプレイヤーが誰であるかを知ることができる.
    これらのプログラムの目的は.

  • そのプレイヤーにログインするたびにログインさせないようにすることです.

  • accesstokenを生成する方法には多くの種類があり、その中で最も広く使用されている技術の一つはJWT(JSON Web Tokens)である.

  • JWTとは,名前の通り,ユーザ情報を含むJSONデータを暗号化してクライアントとサーバとの間で交換するものである.

    • JWTの構造



    header

  • トークンタイプおよびハッシュアルゴリズム情報
  • ヘッダの内容はBASE 64で符号化され、JWTの第1の部分
    • に書き込まれる.
    ex) {“alg”: “HS256”, “typ”: “JWT”}

    payload


    公開クレーム
  • exp、満期時間を示す
  • クライアントとサーバ間の専用クレーム
  • 以上の2つの要素を組み合わせた後、BASE 64は符号化され、2番目の要素
    • に位置する.
    ex) { “user-id” : 1, “exp”: 1539517391 }

    signature


  • JWTが元のバージョンと同じかどうかを確認するときに使用する部分

  • BASE 64 URLとして符号化されたヘッダと負荷、およびJWTsecret(個別に生成)をヘッダに指定された暗号アルゴリズムで暗号化して伝送する(復号可能)

  • 現在のエンドでJWTがバックエンドAPIサーバに送信されると、サーバは送信されたJWTの署名部分を復号し、サーバが生成したJWTが正しいかどうかを確認します.

  • 注意:ヘッダと負荷はBASE 64で符号化されており(暗号化されていない)、誰もが元のファイルを見ることができるため、個人情報を含めることはできません.
    • 生成されたJWTの例eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6Mn0.TqNLDeEa gjSeV6UozaejHx-xOWuzu_6XPHFRvW76Ong

    Token vs ID/PW


  • パフォーマンス:
  • 重いbcryptを必要とせずに簡単なハッシュ
    • を実現できる.

  • クライアントストレージ
  • はCookieのように実際のID/PW
    • を記憶する.
  • は、サイト
    • にのみ適用されます.

    承認プロセス


  • 認証プロセスの使用 アクセスポイントを生成します. 
    アクセスポイントには、ユーザ情報を確認できる情報が含まれているはずです.
    ex) user id

  • プレイヤーがリクエストを送信すると 追加accesstoken送信.

  • サーバが提供する アクセスポイントを復号します.

  • データを復号してユーザidを取得する.

  • useridを使用して、データベースでユーザーの権限を検証します.

  • ユーザーは、リクエストを処理するのに十分な権限を持っています.

  • ユーザに権限がない場合は、Unautorzed Response(401)または他のエラーコードが送信される.
    • 2020.8.5クラスノート(マルチスレッド)
    ログオン原価入取関数