データベース復習(5)

0928

1.HTTPプロトコルの特徴

接続なし:クライアント要求に応答するresを送信し、

接続を切断する.

ステータス情報なし:通信終了後はステータス情報を保持しない

.
=>レコードが失われています.要求されたユーザーを特定できません.
=>アイデンティティと権限の特定が困難

2.認証と認可

1)認証

API要求の利用可能なユーザを決定するプロセス

ユーザーがクライアント宣言のユーザーと同じであることを確認

リクエストの主体が誰であるかを知るためにhttpメッセージのHeader(Not Body!)要求

2）権限（授権）

ユーザーが特定のリソースにアクセスする権限を持っているかどうかを確認する

.

クライアントが実行したいタスクがクライアント

に許可されているかどうか

ユーザーはレベル別アクセス権

を許可する.

の認証を受けると、認証を受けるユーザに特定の権限

が付与される.

3.Cookie/セッション/トークン

HTTPプロトコルの不足を補うために使用

1）クッキー（Cookie）

resを

reqに送信するとともにクッキーの

を送信する.

クッキーは簡単なkey-valueペアです.クライアントローカルストレージ

は、クライアントが最大300個の

を格納できる期間のみを格納する.

サーバからCookieが受信と、WebブラウザはCookieを保存し、要求されるたびにブラウザは自動的に

にCookieを送信する.

サーバは、ユーザが要求した情報をCookieとしてクライアントに送信する.

Cookieは、要求と応答のHeaderに

格納.

ブラウザが閉じても、情報

は保持される.
セキュリティ・ホールは、Butサーバではなくクライアントのローカル・ストレージにあります.

2)セッション

reqが発行すると、サーバエンジンはクライアントに一意のセッションID

を提供する.
ユーザー情報を

サーバ(ローカル以外!)に保存します.セッションidのみでクライアントと通信する

.

は、一定期間、同一ブラウザからの要求を1つの状態とみなし、その状態(Webブラウザが閉じるまで)

を保持する.

クライアントは、Cookieを使用して送信セッションID

を保存する.

セッションはサーバメモリに格納され、サーバが再起動するとセッションデータは消失する(メモリリセット)

.

サーバリソースを使用するため、盲目的に作成するとメモリ使用量が増加し、

の速度が低下します.

安全性が良い

3）タグ

ステータスなし:クライアントに格納、ステータスなし

拡張性:他のサービスと共有できる

ユーザ認証情報は、サーバ、セッション、Cookieに格納されず、サーバ

に容易に拡張できる.
暗号化

による情報格納

4. JWT (Json Web Token)

トークン

は、認証に必要な情報(Jsonオブジェクト)を暗号化する

Access Tokenをhttpヘッダに入れてサーバ

に送信する.

構造

1) HEADER
- 토큰 타입과 해싱 알고리즘이 들어감(암호화시키는 알고리즘)
1) PAYLOAD
- 토큰에 담을 정보가 들어있음. name과 value로 이루어진 하나의 정보(claim)
- 등록된/ 공개/ 비공개 클레임 존재
- iss:토큰 발급자
- exp:토큰 만료시간
- iat:토큰이 발급된 시간. 토큰의 age가 얼마나 되었는지 판단 가능 =>시간은(numericDate형식)
3) SIGNATUER
- 토큰의 유효성 체크 (secret key 이용)를 위해 서명 검증
- 최초 만들때 signature 에서 scret key를 만드는데 짝퉁은 signature 에서 차단

Refresh Token
-Access Token(JWT)を使用して認証を行う方法は、第三者によって盗まれた場合にセキュリティ保護を受けやすい
-トークンの有効期間が長い場合は、セキュリティ上の問題があります.逆に、時間が短い場合は、常にログインする必要があります...
-refresh tokenはAccess Token形式と同じ(約2週間の有効期間)
-accesstokenが期限切れになったときに再発行
-初期ログイン時にアクセスtokenが同時に発行されます

5.Tokenによるサーバ通信実験

昨日行ったMongoDBルータとコントローラに追加

1)JWTによるモジュール化

(1)create:タグ戻りを作成し、パラメータとしてペイロードを受信する(ペイロードはuserIdとname)
(2)verify:生成したトークン値をパラメータとして受信し,暗号化を解放して返す.エラーが発生した場合は、エラーのタイプに応じて-1、-2、-3の値を返します.

2)authModuleを作成し、検証が必要なタスクをミドルウェアとして使用

というBoardという集合をアップロード、修正、削除する場合、ユーザIDはパブリッシャIDと同じである必要がありますので、認証する必要があります.

ヘザー値に、承認/値:AccesToken値、req

と入力します.

tokenでエラーが発生した場合、エラーのタイプに応じてミラーメッセージを出力するように設定されます.

userInfoという変数を作成し、トークンの復号化されたuserIdを入れます.

以降、関数の結果をreqに書き込み、コントローラに移動
3)以降のコントローラにおいて、復号されたトークン値のUserInfoとmongodbに記憶されているIDが一致していることを確認する
4)一致する場合post/update/delete機能を実行します.
5)一致しない場合、エラーメッセージ(「アクセスなし」)が表示されます.