Uenishi.Web

いろいろありすぎてごっちゃになるのでまとめてみた。

随時追加されていくかもしれません。

データを不規則な文字列に変換する手法。

ハッシュ値は復号できないため、パスワードを保管する際などに用いられている。

同じデータから得られるハッシュ値は常に同じのため、ハッシュ値同士を比較することで、元のデータが同一か否かを判断できる。

元のデータにランダムな文字列を 付加してからハッシュ化すること。付加する文字列のことをsalt（ソルト）と呼ぶ。ハッシュ値は同一のデータから同じハッシュ値ができるため、ソルトを加えることでデータを推測されるリスクを軽減する。

一度の認証で複数のサービスを利用できるようにする仕組み

「シングルサインオンを実現する方式の1つに、IDフェデレーションがある」と説明されている。

https://hogetech.info/security/sso/federation

SSOの方式には主に以下の4つがある

• フェデレーション方式
  • 外部の認証サーバー（Idp）で認証しクライアントに認証結果を返す。
  • クライアントがアプリ（SP Service Provider）に認証結果を渡し、アプリを利用
• リバースプロキシ方式
  • 前段のリバースプロキシサーバーで認証。後段のアプリは認証なし。
• エージェント方式
• 代理認証方式

連邦、連合、連盟といった意味を持つ。

異なる複数のシステムやサービスなどを相互運用する

利用者の認証を連携できるようにすることを指すことが多い

独立した複数のシステム間で、標準化された共通のデータ形式やプロトコルに基づいて、認証認可の手続きを横断的に行えるようにすること。

外部の認証サーバー（yahooとかgoogleとか）を利用して、サインイン（ログイン）する仕組み

IDフェデレーションは、以下のいずれかのプロトコルを利用して認証結果を伝送することでSSOを実現する。

• SAML
• OpenID Connect

XML形式の認証結果を送受信する仕組み

（SAMLアサーションを利用して認証結果を送受信する）

アサーションとは？

• 認証ステートメント
• 属例ステートメント
• 認可決定ステートメント

SAML認証にはユーザーの本人性を確認し、SAMLアサーション（XML形式のセキュリティトークン）を発行するIdpと、認証トークンを受け取りログインを受け入れるSP（サービスプロバイダー）が必要

「IDの管理・認証・認可」を指す言葉。

社内アプリケーションやクラウドサービスなど、企業が利用するシステムごとに設定された複数のIDを統合管理する仕組み。

nri-secure.co.jp/glossary/iam

「認可」のための仕組みで、RFC 6749として標準化されている。詳しくは以下（過去記事）へ

OAuth2.0の拡張仕様で、認可のためのプロトコルであったOAuthに対して、「認証」の部分も行えるようにした仕組み。

認証の仕様という説明がよくされているが、以下の記事では「IDトークンを発行するための仕様である」と説明されている。

IDトークンはJWTの一種で、JWSやJWEなどの形式で表現される。

OAuthのパラメーターにもあるscopeにopenidと指定するとID Tokenが発行される。

JSON形式で表現されたクレーム（claim）の集合をJWSもしくはJWEに埋め込んだもの（上記リンクの記事参照）

この辺りは別で記事にしたい。

認証基盤を提供するIDaasサービスのこと。

OAuth2.0やOpenID Connectなどのプロトコルにも対応しており、様々なアプリケーションと連携することができる。

OAuth2.0と名前が似ているから同じようなものかと勘違いしていたけど、ちゃんと調べたら全然違うしなんならサービスなんかい、というお気持ちになった。