今日やったこと

今日は昨日よりほっとした
初めて見た生手の概念が怖いようです.
ずっとそうだった.
初めて概念を学び、この概念の存在を理解することから、
脳の回転数はいつも違います
概念を学び始めたばかりの頃、本当に簡単な問題がたくさん解決できなかったとき
視野が狭くなるの?
この点は改めなければならない

Achievement goals

セッションおよびCookie/TOcken/OAUTHによる認証が可能です.

クライアント、サーバ、およびデータベースの全体的な動作を理解できます.

会員登録および登録などのユーザ認証を実現し理解する.

のサービスセキュリティに関する方法を理解し、原理とメリットとデメリットを理解します.

Token

セッション・ベースの認証は、サーバにユーザー情報を格納する認証方式です.
ただし、セッションはサーバに情報を格納し、サーバのパフォーマンスを低下させる可能性があります.
各リクエストには、サーバまたはデータベースをクエリーする必要があります.まだあります.
1台のサーバでしか使用できないため、複数のサーバを持つサービスにとって、セッションは非効率な認証方法です.
この限界を補う別の認証方式トークンがある.
日常生活では、コインは入場券のような役割を果たしています.

ゲーム機トークン

主催者が

活動に参加するために配布したコイン

遊園地チケット

警備の面でもそうです.
クライアントにトークンがある場合は、そのトークンがないユーザとは異なります.
サーバが提供するさまざまな機能を要求できます.
では、コインは巨大な力を持つ情報です.

JSON Web Token (JWT)

これまでCookieの制限機密情報はクライアントに格納できませんでした.
トークンは暗号化された状態でユーザ情報を格納することができ、暗号化されているのでクライアントに格納することができるという.
クライアントで自分のデータを表示できますが、変更は許可されません.
これらのデータを変更するには、サーバを介して完了する必要があります.
これを可能にしたのはjwtです.

jwtの構造

jwtの構造は3つの小節からなり,各小節はJSON形式で情報を表示する.
JSON形式の各部はBase 64符号化で表される.

Header:データ型、暗号化、ハッシュアルゴリズムに関する情報が含まれます.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload:実際に保存するデータが含まれます.機密情報を含まないほうがいいです.

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

署名:HeaderとPayloadを組み合わせ、秘密鍵(暗号化に追加するsalt)を使用してハッシュ値を作成します.
サーバは、ユーザーが送信したHeaderとPayloadを使用して直接署名を作成します.
以前に送信した署名値と比較します.
値が異なると、偽造されたデータであることがわかります.
秘密鍵はサーバにしか保存できません.クライアントが絶対に知らない値です.

HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

OAuth 2.0

OAuth2.0は、セキュリティリソースにアクセスするためにクライアントに権限(権限)を与えるプロセスを簡略化するプロトコルの1つである.
例えば、Webやアプリケーションでは、ソーシャルログイン認証方式が最近よく見られます.
NAVERログインとKACAログインを実現する簡単な方法は以下の通りです.
ユーザーのNAVERアカウント/パスワードを受信してログインすればいいです.
これは頼りにならない方法だ.
ユーザーにとって、3番目のサービスが自分のNAVERアカウントのパスワードを持つのは危険だからです.
では、どうやって実現するのでしょうか.OAuth 2.0は、他のサービスデータの使用を許可するプロセスであることを説明することができる.言い換えれば、他のサービスの会員情報を安全に利用する方法がより適切かもしれない.

用語

ResourceServer:リソースを持つサーバ(Naver、Kakao)
≪認可サーバー｜Authorization Server｜ldap≫:認証に関連するサーバーを専門に処理します.
≪リソース所有者｜Resource Owner｜ldap≫:リソース・サーバにリソースを所有するユーザー
クライアント:保護されたリソースにアクセスするリソース所有者を表すアプリケーション

ソーシャルログインロジックフロー

以前のソーシャルログイン認証では、アイデンティティ/パスワードを受信せずにデータを受信するにはどうすればいいですか?
OAuth 2.0はEXトークンを利用している.
私たちのサービスはNaverにEXトークンを発行して、あなたの要求に応答します.
そのコインでデータを取得することができます.

Grant type

Authorization Code Grant Type
最も一般的なタイプ
ユーザーの承認後にcodeを受け入れ、エクセストックと交換する方法
EXTAKENを直接受け取るとセキュリティが低下し、クライアントで秘密コードを盗まれやすくなります.

認証コード論理プロセス

Googleのソーシャルサイトを例にとると、ある顧客の登録を会員と仮定すると、
ユーザー(Resourceowner)がクライアント・データベースに格納するデータ
持ってくる場合なら、

ユーザーは、Googleのソーシャル会員登録ユーザーであることをクライアントサーバに証明する必要があります.

これにより、クライアントはユーザー会員情報を持つGoogle(Authorization Server)にユーザーを再起動します.

ユーザーはグーグルにクライアントへのアクセス権を要求した.

Googleはライセンスコードを提供し、クライアントはライセンスtokenを交換します.

クライアントは、認証トークンを使用してクライアントサーバにアクセスできます.

Refresh Token Grant Type

以前のライセンスコード論理ストリームがエクスポートトークンの有効期限が切れたときに実行された場合、非常に面倒です.
Refresh Tokenはこれらの煩雑な論理を減らすことができる.
クライアントはrefresh tokenを取得し、EXSESTOCKをグーグルに転送し、グーグルはrefresh tokenを確認した後、EXSESTOCKを再発行した.

コメントサイト

https://youtu.be/7abbNwuCXbg
https://opentutorials.org/course/3405
https://velog.io/@undefcat/OAuth-2.0-%EA%B0%84%EB%8B%A8%EC%A0%95%EB%A6%AC
https://yonghyunlee.gitlab.io/temp_post/oauth-authorization-code/