TIL.認証権限

認証(認証)
特定のサービスに一定の権限を持つユーザの認証は、ログイン、アイデンティティ、パスワードなどによって取得される.
需要要因-サービス使用追跡
必要-ID Email Password(露出不可)
承認(承認)
ユーザーが認証を取得した後に特定のリソースにアクセスできるかどうかを判断するプロセス.
ex)
NAVERにログインして認証を行った後、ブログに文章やコメントを書くなどして自分のアカウントのアクティビティのみを使用しようとすると、NAVERは私がログインして許可を与えるかどうかを確認します.
💡 なぜ毎回ログインしないのですか?

登録は想像以上に重い仕事です.

データベースに格納ユーザアカウントのハッシュ値

を取り出す.

で入力されたハッシュ値がアルゴリズムで計算されたハッシュ値と一致することを確認します.

リクエストごとにIDとパスワードを送信するのもセキュリティ上の問題です.

簡単に言えば、今使っているidカードがあります.リリースプロセスは認証です.
これは私たちが何階に行けるかを教えてくれた権限で、他の階を押しても反応しませんでした.

Session vs JWT

技術を認める

Session

従来のサーバベースの認証方法
セッションidを使用して、あるユーザがサーバにログインし続ける状態を「セッション」と呼ぶ.
How to Authorization

ユーザログインが成功すると、セッション

が開始する.

セッションをブラウザに保存し、(ex)クロムにsession idに設定されたクッキー)をサーバメモリに格納します.

のライセンスが必要なリクエストを送信すると、セッション値はサーバ

に一斉に送信される.

サーバは、メモリ内の値をセッション値と比較し、適切な値があればライセンスを付与します.

短所

セッションがサーバに格納されるため、ユーザが同時にマルチポイント接続を行う際にメモリが不足する.

サーバが再起動する必要がある場合、サーバメモリに格納されているすべてのセッションが失われ、すべてのユーザーが再ログインする必要があります(データベースの場合、速度が遅い)

.

JWT (JSON Web Token)

ユーザーがログインするとトークンが与えられますが、サーバはこのトークンを覚えていません.

JWT Token例

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

3種類の暗号化データ接続の形式(aaa.bbb.ccc)からなる.

ヘッダ:アルゴリズム(署名値を3回生成するアルゴリズムを指定します.ex)H 256、typeは常にJWTを含みます.)

ペイロード:トークンが所有するデータ

署名(署名):1番ヘッダーに定義されたアルゴリズムにより、暗号化パスワードの値はサーバのみが知る.

なぜ会話に取って代わることができないのか...?

JWTはセッションのようにすべてのユーザの状態を記憶しない.
したがって,記憶対象の状態を随時制御することはできない.
例:
セッションを使用してログインを作成する場合、1台のデバイスにしかログインできないサービスを作成したい場合は、pcログイン、携帯電話のセッション値の無効化などで制御できます.
しかし、JWTもすでに発行されたコインを奪うことはできない.また、トークンを奪われても無効にすることはできません.
これには、ログイン時のaccessTokenとrefreshTokenの2つのソリューションがあります.
accessToken:承認されるたびに使用されるコインで、一般的に寿命が短い.
refreshToken accessTokenの寿命が終わると、accessTokenを再実行するために使用されるトークンは、通常2週間の有効期間を有する.