-
Notifications
You must be signed in to change notification settings - Fork 0
MS_Token
-
TOP > インフラストラクチャ > 認証基盤
- トークン
- クレームベース認証
- ワンタイム・パスワード
トークンには色々な意味があるが、
ここでは、セキュリティ対策や認証・認可などの処理のための、
認証チケット(証拠)などで使用するトークンについて説明する。
認証・認可で使用するトークンにも様々なものがアル。
-
コンピュータ・サービスの利用権限のある利用者に、
認証の助けとなるよう与えられる物理デバイス -
ハードウェア・トークン、認証トークン、暗号トークンとも呼ばれる。
以下のようなタイプが有り、基本的に物理デバイスのもの。
- Bluetooth 型トークン
- 携帯電話
- 非接続型トークン
- PC カード型トークン
- スマートカード型トークン
- USB 型トークン
- スマートカード・USB 型トークン
※ 昨今の物理デバイス上の TPM(MS_TPM.md)を使用した
ソフトウェア・トークンも入れて良さそう。
補足(最新化): この「TPM を使ったソフトウェア トークン」という見立ては、 現在では FIDO2 / WebAuthn のプラットフォーム認証器として実現している。 Windows Hello は TPM に鍵を封じ込め、 ハードウェア トークンに近い保護を得ながら、 追加のデバイスを配らずに済む。 詳細は FIDO を参照。
-
デジタル署名
- 利用者だけが署名鍵にアクセスできることが満たされている必要がある。
- 署名は利用者の識別情報の証明にも使えるので、ユーザ認証にも使用できる。
-
SSO ソフトウェア
- シームレスな認証や、password filling を行なう場合がある。
- 同様に、暗号化技術が使用され、改ざん等が無いか検証可能になっている。
-
ワンタイムパスワード
- ログイン毎や、時間経過で変化するタイプ
- チャレンジ&レスポンスなどもワンタイムパスワード
(ワンタイム・パスワード を参照)
当該アクセスに添付され認証・認可をするためのアサーション。
従って、以下が含まれた情報。
- 認証・認可に必要なクレームから構成されるクレームセット
- 認証オーソリティによって上記に署名を加えたコントラクト(契約)
署名には、暗号化技術が使用され、改ざん等が無いか検証可能になっている。
-
Digest 認証、Basic 認証の Credential もある種の認証トークンと言える。
ユーザ ID とパスワードの情報を含んでいる(クレームセット → アサーション)。 -
Authorizationヘッダ情報に設定される。
Bearer Token も OAuth に限らず、一般的な HTTP 認証トークンとして使用可能。- RFC 7235 で
Authorization: auth-scheme (token68 / auth-params)が定義済みで、
auth-schemeには Basic, Digest に加え Bearer が登録済み(IANA により管理)。
- RFC 7235 で
-
持参人切符 : Bearer Token
- 通常の OAuth の Token は「bearer・token」。
- 「bear(持ってきた)+ er(人)」=「持参人」。
- 具体的には「電車」の「切符」のこと。
- 持参人は誰でも、切符が有効ならば利用可能。
-
記名式切符
- 上記「切符」に対し、名前が書かれた「国際線」の「ボーディングパス」など。
- ゲートでは、名前・顔とパスポートの記載が一致するかを確認する。
- 誰かがボーディングパスを盗んでも、使うことはできない(盗難 & 再生の防止)。
- 記名式切符には、色々な呼び方がある。
- Sender Constrained Token
- User Constrained Token
- Holder-of-Key Token
- Proof-of-possession Token
補足(最新化): 「記名式切符」を実現する仕様は、その後かなり整理された。
仕様 内容 mTLS(RFC 8705) クライアント証明書にトークンを結び付ける DPoP(RFC 9449) クライアントの鍵で毎回の要求に署名する。SPA / モバイル向き Token Binding(RFC 8471〜) TLS 層で束縛。ブラウザ実装が撤退し、事実上停止 元ページが挙げていた MAC Token は draft のまま廃案になり、 現在は DPoP が SPA・ネイティブ アプリでの事実上の標準である。 金融系(FAPI 2.0)では mTLS または DPoP が必須要件になっている。
Bearer Token は「盗まれたら誰でも使える」ため、 SSL/TLS による保護と短い有効期限が前提である。
-
SAS: Shared Access Signatures(共有アクセス署名)
-
1 つまたは複数のリソースを指す署名付き URI
-
昨今、クラウド関連のサービスで使用されることが多い。
-
OneDrive の共有(URL)のような機能で利用されることが多い。
- URI のトークン(QueryString のパラメタセット)が含まれている。
- パラメタの 1 つにパラメタセットに対する署名がある。
- リソースへのクライアントのアクセス方法を示す(認可)。
-
基本的に、ポータルなどから入手することが多いが、
プログラムから、SAS トークンを生成することもできる
(必要なパラメタセットを署名することで生成できる)。 -
以下の様なサービスで使用されている。
- Azureのストレージ(
MS_AzureStorage.md) - Azure IoT Hub(
MS_AzureIoTHub.md) - Azure Event Hubs(
MS_AzureEventHubs.md)
- Azureのストレージ(
補足: SAS トークンは URL そのものが資格情報である。 アクセス ログ・リファラ・ブラウザ履歴に残ると漏れるため、 有効期限を短くし、可能なら ユーザ委任 SAS(Microsoft Entra ID の資格情報で署名)を使うこと。 ストレージ アカウント キーで署名した SAS は、 キーを失効させない限り取り消せない。
- 認証・認可用ではないが、CSRF を防止するための単なる乱数もトークンと呼ぶ。
- 正規のリクエストなのか、攻撃者のリクエストなのかを判断できる。
CSRF(XSRF)対策の実装方針(MS_CSRFCountermeasures.md)を参照。
認証・認可プロトコルのトークンの用語。
※ セキュリティ トークンにはあまり難しい用語は無い。
- 対象となるエンティティ("サブジェクト")に関する事実の情報
- クレームの集合が、クレームセットになる。
以下の様な標準仕様を見ると、
- Assertions and Protocols for the OASIS SAML V2.0
- RFC 7519 - JSON Web Token (JWT)
それぞれ、以下のように定義されている。
| 語 | 定義 |
|---|---|
| トークン | 「複数のクレーム(クレームセット)」を格納する「アサーション」 |
| トークン・プロファイル | 「アサーション」のフォーマット |
・・・従って、「アサーション」≒「トークン」らしい。
≒ 表明:(自分の考え・決意などを、)はっきりあらわし示すこと。
プログラムの前提として満たされるべき条件を記述するもの。
- 複数のクレーム(クレームセット)から構成され、
- 何らかの対象に関する属性や設定などの情報を列挙した、
データ集合を指す場合が多い。 - 認証・認可では、単なる属性ではなく、認証ユーザの ID や資格・権限情報、
その他の属性情報の表明のためのデータ集合として使用される。 - 標準化された技術仕様において、
適用場面の限られたオプション仕様などのことをプロファイルということがある。
- 何らかの対象に関する属性や設定などの情報を列挙した、
以下、RFC 7521 からの引用。
- セキュリティドメイン間で ID とセキュリティ情報の共有を容易にする情報のパッケージ
- アサーションには、通常、以下のような情報が含まれる。
- 主体または主体に関する情報
- アサーションを発行した当事者に関する情報
- およびアサーションが発行された日時
- およびアサーションが有効であるとみなされる条件
(たとえば、いつどこで使用できるかなど)
用語
| 語 | 意味 |
|---|---|
| 発行者 | アサーションを作成し、署名し、完全性保護するエンティティ |
| 依拠当事者 | アサーションを消費し、その情報に依存するエンティティ |
上記の文脈上からは、
- 先ず、SAMLアサーションや JWTアサーションなどの
標準仕様があり、 - それを SAML や OAuth、OpenID Connectで使用する際の
オプション仕様を、「トークン・プロファイル」と言う。
ざっくり、アサーションを実際に使うとトークン。
解り易いのが、JWT アサーションをアクセストークンとして使用する例。
補足: 実装で混同しやすいのは、 OpenID Connect の ID トークンとアクセス トークンの用途の違いである。
トークン 宛先 用途 ID トークン クライアント 「誰がログインしたか」を伝える(認証) アクセス トークン リソース サーバ(API) 「何をしてよいか」を伝える(認可) ID トークンを API に送って認可判断に使う、 アクセス トークンの中身を読んでユーザを識別する、 といった実装はいずれも誤りである。 WebAPIの認証 も参照。
- 認証基盤
- クレームベース認証
- ワンタイム・パスワード
-
JWT / SAML / CWT(
MS_CWT.md) - RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
- RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- OAuthで「記名式」トークンを使うもう一つの方法 | @_Nat Zone
- OAuth アクセストークンの実装に関する考察 - Qiita
Tags: セキュリティ, 認証基盤, 暗号化
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。