OAuth 2.0

第三者アプリケーションにリソースへのアクセスを委任するための認可フレームワーク。アクセストークンを用いてリソースサーバにアクセスする。認可コードフロー、クライアントクレデンシャルフローなど複数の認可フローがある。

Webサービス間で認可情報を安全に委譲するためのプロトコル。リソースオーナーの許可を得て、サービス（クライアント）に対してアクセストークンを発行し、適切な権限の範囲内でリソースへのアクセスを許可する。認証ではなく認可のためのプロトコルである。

利用者のパスワードを第三者のアプリケーションに渡すことなく、そのアプリケーションに特定のリソースへのアクセス権限を委譲するための認可の標準規格。認可サーバが発行したアクセストークンでAPIなどにアクセスさせる仕組みで、権限の範囲（スコープ）と有効期間を限定できる。認証の仕組みではない点に注意する。

トランスポート層で通信の暗号化・認証・改ざん検知を提供するプロトコル。TLS 1.3では暗号スイートがAEADとハッシュアルゴリズムの組みに簡素化され、ハンドシェイクの効率化とセキュリティ強化が図られた。HTTPS、IMAPS、SMTPS等で広く利用される。

HTTPの通信をTLSで保護する方式。サーバ証明書による接続先の確認、通信内容の暗号化、改ざん検知を実現する。既定のポート番号は443で、現在はすべてのWebサイトで常時利用することが推奨される。

UDP上に構築された、暗号化と多重化を前提とする通信プロトコル。TLSの機能を組み込んで接続確立の往復回数を削減し、パケット損失が1本のストリームに閉じるためHTTP/3の下位層として採用されている。

利用者IDや有効期限などの情報（クレーム）をJSONで表し、デジタル署名やMACを付けて改ざんを検知できるようにしたトークン。署名付きのJWTは、ヘッダー・ペイロード・署名をそれぞれBase64URLで符号化し、ピリオドでつないだ文字列で表す。OpenID ConnectのIDトークンやAPIのアクセストークンに使われ、受け取った側が署名とアルゴリズム（alg）を正しく検証しないと、改ざんされたトークンや署名のないトークン（alg=none）を受け入れてしまう。

Webサーバとクライアント間でHTMLなどのリソースを転送するためのプロトコル。リクエスト-レスポンス型の通信モデルを採用し、GET、POST、PUT、DELETE等のメソッドを使用する。HTTP/2では多重化やヘッダ圧縮、HTTP/3ではQUICによる高速化が行われている。

実行中のアプリケーションに対して外部から疑似的な攻撃リクエストを送信し、脆弱性を検出するテスト手法。ソースコードを必要とせず、ブラックボックス的に検査する。XSS、SQLインジェクション、認証の不備などを実際の動作環境で発見できる。