権限

ユーザがサーバにログインした後,そのユーザが正しいかどうかを確認するプロセスが承認である.
認証が必要な理由は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)または他のエラーコードが送信される.