JSON Web Token #Security/Authentication トークン自体の情報（例: 期限）を自身で構造化して保持することで、共有データベースへ保持・検索をする必要がないトークン。トークンが自身の情報を持つことで外部からのトークン取り消しのような操作はできない JWTは.によって3つのセクションの文字列に分割できる（署名がない場合3つ目のセクションは空） それぞれのセクションの文字列は構造化されたJSONをBase64URLエンコードした結果となっている ヘッダー 1つ目のセクションはヘッダーとして以下のような構造を持つ { "typ": "JWT", "alg": "RSA256" } algで指定する署名アルゴリズムは3つ目の署名セクションの解読にて用いる ペイロード 2つ目のセクションはトークン自体のペイロードになる。ペイロードの中身はJSONであれば自由だが、JWTクレームと呼ばれる役割が明示・明示された項目群が存在する。 例として　iss（発行者）、sub（対象者）、exp（有効期限）などがある 署名 3つ目のセクションはHMACやRSAのような署名アルゴリズムを使った結果が保持される RFC 7519 - JSON Web Token (JWT)

#Programming #Security/Authentication Go用のOIDCライブラリ、golang.org/x/oauth2パッケージと統合される プロバイダーのDiscoveryエンドポイントから自動設定 IDトークン（JWT）の署名検証とクレーム抽出 リモートのJWKS取得とキャッシュ管理 https://github.com/coreos/go-oidc

Multi Factor Authentication 多要素認証 #Security/Authentication

#Software Design #Cloud Native #Security/Authentication #Security/Authorization The Twelve-Factor Appを現代のクラウドネイティブ環境向けに拡張した方法論。Kevin Hoffmanによって著され、オリジナルの12要因を15要因に拡張している。 追加された3つの新要因 2. API First - サービス設計において、実装前にAPIインターフェースを定義し契約駆動開発を促進 #API Architecture 14. Telemetry - メトリクス、ログ、トレースの収集を通じた包括的な監視機能 #Observability 15. Authentication and Authorization - 認証・認可をアプリケーション設計の第一級の関心事として組み込む Authentication / Authorization 既存要因の改訂 Kubernetes ConfigMap/Secretsなどコンテナ時代の設定管理や、Infrastructure as Code（IaC）による環境構築など、現代的なベストプラクティスを反映した注釈が追加されている。 https://www.vmware.com/docs/ebook-beyond-the-12-factor-app

#Security/Authentication DIDにおいてスキーム部の後に続き、名前空間として機能する。名前空間に対しDIDドキュメントというメソッド固有の仕様を解決できる 例として、イーサリアムブロックチェーンメソッドを使用するDIDは did:eth から始まる

#Security/Authentication #Security/Authorization DIDにおいて自己証明自律型識別子を提供する did:peer DIDメソッド定義 DIDドキュメント相当の情報をパブリックに公開しないため、安価でありセキュリティ強化に繋がる authorization セクションによる認可制御が可能 https://identity.foundation/peer-did-method-spec/

#Security/Authentication 認証の実装指針をまとめたOWASP Cheat Sheet Series Session Management zxcvbn-ts Pwned Passwords TLS Client Authentication MFA OAuth2 OpenId SAML Brute Force https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

#Security/Authentication セッション管理の実装指針をまとめたOWASP Cheat Sheet Series HTTP Cookie https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

#Security/Authentication ingressgatewayに対して、JWTの検証を行うためのカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/request_authentication/

#Security/Authentication Istioにおいてマイクロサービス間のmTLSを設定するカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/peer_authentication/

#Security/Authentication GitHub App の User Access Token をローカル開発向けに発行する CLI。Device Flow で認証し、8 時間で失効する短命トークンを払い出すことで、長命トークン（PAT や gh auth login の OAuth トークン）が漏洩した際のリスクを抑える 特徴 発行するのは User Access Token で、操作は App ではなくユーザー本人の権限・名義で行われる GitHub App の Client ID のみで動作し secret は不要。失効後は ghtkn get が Device Flow で自動再発行する トークンは OS の資格情報ストア（macOS Keychain / Windows Credential Manager / GNOME Keyring）に保存し、期限まで再利用する https://github.com/suzuki-shunsuke/ghtkn

CA #Security/Authentication 信頼されたデジタル証明書の発行者

Identity Provider #Security/Authentication #Security/Authorization デジタルアイデンティティシステムにおいて、ユーザーの認証を行い、アイデンティティ情報を提供するサービスまたは組織 代表的なソーシャルIdPとして、Google、Facebook、GitHub、Microsoftなどがある OIDCやOAuth2プロトコルを用いてアイデンティティ情報を外部アプリケーションに提供する

#Security/Authentication ブルートフォース攻撃を防ぐための対策をまとめたOWASP Communityの記事 主な対策方法 アカウントロックアウト機能（DoS攻撃に悪用されるリスクに注意） Device Cookies（デバイスごとの認証ロック機構、DoS攻撃に対して耐性がある） パスワード検証時の遅延追加 IPアドレスベースのレートリミット CAPTCHAの導入 複数の秘密の質問による認証強化 単一の技術では回避されやすいため、複数の対策を組み合わせることが重要 https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

#Security/Authentication #Security/Authorization ゴールドスタンダード（Gold Standard）は、セキュアなシステム設計における基本原則で、C-I-Aを保護する執行メカニズムとして機能します。 認証（Authentication）: ユーザーが本人であることを証明 認可（Authorization）: 認証されたユーザーの行動の許可・拒否を決定 監査（Auditing）: システムアクティビティの信頼できるログを維持 ラテン語で金を意味する「Aurum」の化学記号「Au」に由来し、3つの原則が「Au」で始まることからこの名称が付けられています。 https://designingsecuresoftware.com/text/ch1-gold/

JSON Web Key Set #Security/Authentication #Security/Cryptography JWTの署名検証に用いる公開鍵群をJSON形式で表現する仕様（RFC 7517）。各キーはkid（Key ID）・kty（鍵種別）・alg（署名アルゴリズム）などのフィールドを持ち、配列としてまとめられる JWT認証プロバイダーは/.well-known/jwks.jsonのようなエンドポイントで公開し、リライングパーティはJWTヘッダーのkidで該当キーを選択して署名を検証する。鍵ローテーションは新旧キーの並存で実現する RFC 7517 - JSON Web Key (JWK)

#Security/Authentication 簡単かつ安価にDV証明書を発行する認証局 https://letsencrypt.org/ja/

Security Assertion Markup Language #Security/Authentication XMLベースの認証・認可データ交換標準規格。IdPとSP（Service Provider）間で認証情報をやり取りし、SSO（Single Sign-On）を実現する。 https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

#Security/Authentication GitHub の機能を拡張するために作る integration の一種。アカウントにインストールして使い、付与した権限の範囲で動く。ユーザー本人に紐づく PAT と異なり、独立した主体として振る舞う サードパーティツールを GitHub と連携させる際の install 先として使うのが典型。App の ID と private key で認証し、短命のインストールアクセストークンを払い出すこともできる。 https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps

Completely Automated Public Turing test to tell Computers and Humans Apart #Security/Authentication 人間とボット（自動プログラム）を区別するための技術 主な目的はブルートフォース攻撃の防止、スパムやボットによる自動投稿の防止、不正なアカウント作成の防止 代表的な実装として、Google reCAPTCHA、hCaptcha、テキストベースCAPTCHAなどがある アクセシビリティの観点から、音声CAPTCHAなどの代替手段の提供が推奨される https://www.cloudflare.com/ja-jp/learning/bots/how-captchas-work/

#Security/Authentication 既知のデータ侵害で利用されたパスワードかどうかを検証できるサービス、API https://haveibeenpwned.com/Passwords

#Security/Authentication 一定回数の不正なパスワード入力後にアカウントを一時的または永続的にロックするブルートフォース攻撃対策 主な問題点 DoS攻撃の標的になりやすい（攻撃者が大量のアカウントをロック可能） ユーザー名の列挙が可能（存在するアカウントのみがロックされる） ヘルプデスクへの負担増加 低速攻撃や複数ユーザー対象の攻撃に無効

#Team Organization #Security/Authentication #Security/Authorization Team Topologiesにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する

Personal Access Token #Security/Authentication GitHub のユーザー本人として API / Git 認証に使う個人向けアクセストークン。パスワードの代わりとなる認証情報で、HTTPS での Git 操作や gh CLI、外部サービスからの GitHub 連携に用いる 特徴 classic と fine-grained の 2 種類があり、fine-grained はリポジトリ単位・権限単位でスコープと有効期限を絞れる ユーザー権限を継承する長命トークンになりやすく、最小権限と短い有効期限の設定が推奨される https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

#Security/Authentication HTTPプロトコルにおける認証方式 ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う

System for Cross-domain Identity Management #Security/Authentication ユーザーアイデンティティ情報を異なるシステム間で自動的にプロビジョニング・管理するための標準プロトコル 主な機能は以下の通り ユーザープロビジョニング（新規アカウント作成） デプロビジョニング（アカウント削除） 属性同期（ユーザー情報の更新） グループ管理 RESTful APIベースで、IdPとSP（Service Provider）間のユーザー情報同期を効率化する https://scimcloud.com/ https://datatracker.ietf.org/doc/html/rfc7644

#Security/Authentication TypeScriptで書かれた、パスワード強度を検証するライブラリ https://github.com/zxcvbn-ts/zxcvbn

#Security/Authentication 公開鍵と名前や住所等の識別情報を組み合わせることで、鍵の所有者を識別し正しい鍵であることを保証する証明書 認証局にデジタル署名をさせて発行される

#API Architecture #Network #Security/Authentication #Security/Authorization 外部トラフィックに対してリバースプロキシ・ロードバランシングが持つようなネットワークのルーティング・セキュリティと可用性の向上に加え、以下のような機能横断的な要件を扱う役割 認証 認可 レートリミット リトライ サーキットブレーカー etc.

分散型識別子 #Security/Authentication 暗号識別子の一種である。W3Cの分散型識別子ワーキンググループによってDID仕様が定義される 以下のような特性を持つ 再割り当て不可 解決可能 DIDメソッドを元にしたDIDドキュメントの取得 所有権の証明 デジタル署名 非集中型 URIとして表現され、以下例のような構文になる did:example:123456789abcdefghij did スキーム部、 did で固定 example メソッド部 123456789abcdefghij メソッド固有識別子部 https://www.w3.org/TR/did-1.0/

#Security/Authentication ブルートフォース攻撃を軽減するための認証ロック機構。ユーザーが正常に認証された後、そのブラウザに発行される特別なCookie 従来のアカウントロックアウトと比較して以下の利点がある DoS攻撃に対して耐性がある IPアドレスではなくブラウザCookieを基準とするため予測可能で実装しやすい ボットネットや代理経由の攻撃に対応しやすい 認証リクエスト時に有効なDevice Cookieの有無を確認し、未信頼クライアント（Device Cookieなし）からの認証試行回数を記録してロックアウトを実施する 実装にはJWT、Redis/Memcachedによるロックリスト管理、HMAC署名による改ざん防止などが用いられる https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies

#Security/Authentication 総当たり攻撃。パスワードや暗号鍵などを、可能な組み合わせを全て試すことで解読を試みる攻撃手法 対策として以下のような方法がある 強力なパスワードポリシーの適用（zxcvbn-ts、Pwned Passwordsによる検証） アカウントロックアウト機能 レートリミットによるログイン試行回数の制限 MFAの導入 CAPTCHAの利用 https://www.ipa.go.jp/security/vuln/websecurity/brute-force.html

#Security/Authentication DIDにおいて、識別された主体と対話を開始するために必要な公開鍵、認証プロトコル、サービスエンドポイントが記述されている