// Double#doubleToRawLongBits(double)} spec.
  static final long SIGN_MASK = 0x8000000000000000L;

  static final int SIGNIFICAND_BITS = 52;

  static final int EXPONENT_BIAS = 1023;

  /** The implicit 1 bit that is omitted in significands of normal doubles. */
  static final long IMPLICIT_BIT = SIGNIFICAND_MASK + 1;

  static long getSignificand(double d) {
    checkArgument(isFinite(d), "not a normal value");

   * TBSCertificate ::= SEQUENCE  {
   *   version         [0]  EXPLICIT Version DEFAULT v1,
   *   serialNumber         CertificateSerialNumber,
   *   signature            AlgorithmIdentifier,
   *   issuer               Name,
   *   validity             Validity,
   *   subject              Name,
   *   subjectPublicKeyInfo SubjectPublicKeyInfo,
   *   issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3

The most common is the implicit flow.

The most secure is the code flow, but it's more complex to implement as it requires more steps. As it is more complex, many providers end up suggesting the implicit flow.

/// note

It's common that each authentication provider names their flows in a different way, to make it part of their brand.

    * HTTP Basic 认证方式。
    * HTTP Digest，等等。
* `oauth2`：所有的 OAuth2 处理安全性的方式（称为「流程」）。
    *以下几种流程适合构建 OAuth 2.0 身份认证的提供者（例如 Google，Facebook，X (Twitter)，GitHub 等）：
        * `implicit`
        * `clientCredentials`
        * `authorizationCode`
    * 但是有一个特定的「流程」可以完美地用于直接在同一应用程序中处理身份认证：
        * `password`：接下来的几章将介绍它的示例。
* `openIdConnect`：提供了一种定义如何自动发现 OAuth2 身份认证数据的方法。

        fw.println("#");
        fw.println("# The checker does not handle implicit section names, so they must be explicit and declared as: [[section-name]]");
        fw.println("#");
        fw.println("# The checker also rejects Markdown-style links, such as [text](https://example.com/something) as they do not render properly");

    * HTTP Basic 驗證。
    * HTTP Digest 等。
* `oauth2`：所有 OAuth2 的安全性處理方式（稱為「flows」）。
    * 其中數個 flow 適合用來建立 OAuth 2.0 身分驗證提供者（如 Google、Facebook、X（Twitter）、GitHub 等）：
        * `implicit`
        * `clientCredentials`
        * `authorizationCode`
    * 但有一個特定的 flow 可直接在同一個應用中處理身分驗證：
        * `password`：後續幾個章節會示範這個。
* `openIdConnect`：提供一種方式來定義如何自動發現 OAuth2 的身分驗證資訊。
    * 這種自動探索機制即由 OpenID Connect 規範定義。

    * HTTP Basic認証
    * HTTP ダイジェスト認証など
* `oauth2`: OAuth2のセキュリティ処理方法（「フロー」と呼ばれます）のすべて。
    * これらのフローのいくつかは、OAuth 2.0認証プロバイダ（Google、Facebook、X (Twitter)、GitHubなど）を構築するのに適しています。
        * `implicit`
        * `clientCredentials`
        * `authorizationCode`
    * しかし、同じアプリケーション内で認証を直接処理するために完全に機能する特定の「フロー」があります。
        * `password`: 次のいくつかの章では、その例を紹介します。
* `openIdConnect`: OAuth2認証データを自動的に発見する方法を定義できます。

 *   <li>reportActiveExternalHost: The external IP address to report in active mode.</li>
 *   <li>useEPSVwithIPv4: Whether to use EPSV with IPv4.</li>
 *   <li>isImplicit: Whether to use implicit SSL/TLS encryption.</li>
 *   <li>trustManager: The trust manager to use for SSL/TLS connections ("all", "valid", or "none").</li>
 *   <li>enterLocalPassiveMode: Whether to enter local passive mode.</li>

自分たちで管理しているため、`username` と `password` を受け取る相手を信頼できるからです。

しかし、他者が接続する OAuth2 アプリケーション（Facebook、Google、GitHub などに相当する認証プロバイダ）を構築する場合は、他のいずれかのフローを使用すべきです。

最も一般的なのは implicit フローです。

最も安全なのは code フローですが、手順が多く実装がより複雑です。複雑なため、多くのプロバイダは結局 implicit フローを推奨することがあります。

/// note | 備考

各認証プロバイダがフローに独自の名称を付け、自社のブランドの一部にするのは一般的です。

しかし、最終的には同じ OAuth2 標準を実装しています。

///

class OAuthFlowClientCredentials(OAuthFlow):
    tokenUrl: str


class OAuthFlowAuthorizationCode(OAuthFlow):
    authorizationUrl: str
    tokenUrl: str


class OAuthFlows(BaseModelWithConfig):
    implicit: OAuthFlowImplicit | None = None
    password: OAuthFlowPassword | None = None
    clientCredentials: OAuthFlowClientCredentials | None = None
    authorizationCode: OAuthFlowAuthorizationCode | None = None