OIDC サインインを iOS (Swift) で構築する方法

新しい友達のために:

Logto は、モダンなアプリや SaaS 製品向けに設計された Auth0 の代替です。 Cloud とオープンソースの両方のサービスを提供し、アイデンティティと管理 (IAM) システムを迅速に立ち上げるのに役立ちます。認証 (Authentication)、認可 (Authorization)、マルチテナント管理をすべて一つにまとめて楽しんでください。

Logto Cloud で無料の開発テナントから始めることをお勧めします。これにより、すべての機能を簡単に探索できます。

この記事では、iOS (Swift) と Logto を使用して、OIDC サインイン体験（ユーザー認証 (Authentication)）を迅速に構築する手順を説明します。

前提条件

稼働中の Logto インスタンス。紹介ページをチェックして始めてください。
iOS (Swift) の基本的な知識。
使用可能な OIDC アカウント。

Logto でアプリケーションを作成する

Logto は OpenID Connect (OIDC) 認証 (Authentication) と OAuth 2.0 認可 (Authorization) に基づいています。これは、複数のアプリケーション間でのフェデレーテッドアイデンティティ管理をサポートし、一般的にシングルサインオン (SSO) と呼ばれます。

あなたの Native app アプリケーションを作成するには、次の手順に従ってください：

Logto コンソールを開きます。「Get started」セクションで、「View all」リンクをクリックしてアプリケーションフレームワークのリストを開きます。あるいは、Logto Console > Applications に移動し、「Create application」ボタンをクリックします。
開いたモーダルで、左側のクイックフィルターチェックボックスを使用して、利用可能なすべての "Native app" フレームワークをフィルタリングするか、"Native app" セクションをクリックします。"iOS (Swift)" フレームワークカードをクリックして、アプリケーションの作成を開始します。
アプリケーション名を入力します。例：「Bookstore」と入力し、「Create application」をクリックします。

🎉 タダーン！Logto で最初のアプリケーションを作成しました。詳細な統合ガイドを含むお祝いページが表示されます。ガイドに従って、アプリケーションでの体験を確認してください。

iOS (Swift) SDK を統合する

Logto SDK を依存関係として追加する

注記:

The minimum supported iOS version of Logto Swift SDK is iOS 13.

Logto Swift SDK comes in two major versions:

v1: Opens the sign-in experience in an embedded WebView, which is required by the native social plugin targets, but does not support passkey sign-in (WebView does not support WebAuthn, the underlying standard of passkeys).
v2 (beta): Opens the sign-in experience in ASWebAuthenticationSession (the system browser), which unlocks passkey sign-in and shares the browser session. Note that v2 removes the native social plugin targets; social connectors still work through the browser. If you depend on the native WeChat or Alipay SDK handoff, stay on v1.

This guide covers both versions. Choose your version in the tabs below, and the choice will be kept in sync throughout this guide.

Use the following URL to add Logto SDK as a dependency in Swift Package Manager.

https://github.com/logto-io/swift.git

Since Xcode 11, you can directly import a Swift package w/o any additional tool.

When Xcode asks for the package version, choose the version you want to integrate:

v2 (beta)
v1

v2 is released as 2.0.0-beta.x prereleases until GA. Use 2.0.0-beta.1 or the latest 2.0.0-beta.x prerelease as the version. During beta, we recommend selecting the prerelease explicitly instead of relying on a normal version range to pick it automatically.

If you use Package.swift directly:

Package.swift
.package(url: "https://github.com/logto-io/swift.git", exact: "2.0.0-beta.1")

Use the latest v1 release as the stable line. The latest v1 version is 1.2.0.

If you use Package.swift directly:

Package.swift
.package(url: "https://github.com/logto-io/swift.git", from: "1.2.0")

We do not support Carthage and CocoaPods at the time due to some technical issues.

Carthage

Carthage needs a xcodeproj file to build. We will try to find a workaround later.

CocoaPods

CocoaPods does not support local dependency and monorepo, thus it's hard to create a .podspec for this repo.

LogtoClient を初期化する

LogtoConfig オブジェクトを使用して LogtoClient インスタンスを作成することで、クライアントを初期化します。

ContentView.swift
import Logto
import LogtoClient

let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>", // 例: http://localhost:3001
  appId: "<your-app-id>"
)
let client = LogtoClient(useConfig: config)

備考:

デフォルトでは、ID トークンやリフレッシュトークンのような資格情報を Keychain に保存します。したがって、ユーザーは戻ってきたときに再度サインインする必要はありません。

この動作をオフにするには、usingPersistStorage を false に設定します：

let config = try? LogtoConfig(
  // ...
  usingPersistStorage: false
)

詳細に入る前に、エンドユーザー体験の概要を簡単にご紹介します。サインインプロセスは次のようにシンプルにまとめられます：

アプリがサインインメソッドを呼び出します。
ユーザーは Logto のサインインページにリダイレクトされます。ネイティブアプリの場合は、システムブラウザが開かれます。
ユーザーがサインインし、アプリ（リダイレクト URI として設定）に戻されます。

この認証 (Authentication) プロセスは OpenID Connect (OIDC) プロトコルに従い、Logto はユーザーのサインインを保護するために厳格なセキュリティ対策を講じています。
複数のアプリがある場合、同じアイデンティティプロバイダー (Logto) を使用できます。ユーザーがあるアプリにサインインすると、Logto は別のアプリにアクセスした際に自動的にサインインプロセスを完了します。

リダイレクトベースのサインインの理論と利点について詳しく知るには、Logto サインイン体験の説明を参照してください。

Configure redirect URI

v2 (beta)
v1

Logto コンソールのアプリケーション詳細ページに切り替えましょう。リダイレクト URI io.logto.app://callback を追加し、「変更を保存」をクリックします。

In v2, the sign-in experience opens in ASWebAuthenticationSession (the system browser), and the redirect is routed back to your app through OS-level callback matching. For a custom scheme redirect URI such as io.logto.app://callback, register only the scheme part (io.logto.app) in your app's Info.plist, then add the full redirect URI to your Logto application's Redirect URIs.

In Xcode, open your app target, select Info, expand URL Types, and add one entry with io.logto.app in URL Schemes. If you edit Info.plist directly, add:

Info.plist
<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleTypeRole</key>
    <string>Editor</string>
    <key>CFBundleURLName</key>
    <string>io.logto.app</string>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>io.logto.app</string>
    </array>
  </dict>
</array>

For the browser flow in v2, you do not need to call LogtoClient.handle(url:); that plugin handoff API was removed with the embedded WebView flow.

Use Universal Links instead of a custom scheme?

You can also use an HTTPS redirect URI such as https://example.com/callback:

Add the Associated Domains capability to your app.
Configure webcredentials:example.com so ASWebAuthenticationSession can match HTTPS callbacks on iOS 17.4 and newer.
If the same URL should also open your app as a Universal Link outside the authentication session, configure applinks:example.com and host a valid apple-app-site-association file for the domain and path.
Add the HTTPS URI to your Logto application's Redirect URIs.
Pass the same URI to signInWithBrowser.

On iOS 17.4 and newer, the SDK uses ASWebAuthenticationSession's HTTPS callback matching API so HTTPS redirects can automatically complete and dismiss the session. On older iOS versions, the authorization request can still use the HTTPS redirect URI, but the session may not close automatically unless your app handles the Universal Link callback itself. Keep a custom scheme redirect as a compatibility option if you need automatic completion on older iOS versions.

Logto コンソールのアプリケーション詳細ページに切り替えましょう。リダイレクト URI io.logto://callback を追加し、「変更を保存」をクリックします。

備考:

The Redirect URI in iOS SDK is only for internal use. There's NO NEED to add a Custom URL Scheme until a connector asks.

注記:

.signInWithBrowser(redirectUri:) を呼び出す前に、Admin Console でリダイレクト URI が正しく設定されていることを確認してください。 :::

v2 (beta)
v1

In v2, client.signOut(postLogoutRedirectUri:) performs a complete sign-out: it clears the local credentials, revokes the refresh token, and ends the Logto session by opening the end session endpoint in the system browser. The browser then navigates back to your app through the post sign-out redirect URI. Before using it, switch to the application details page of Logto Console, add the post sign-out redirect URI io.logto.app://signed-out and click "Save changes". The post sign-out redirect URI can use the same custom scheme you registered for sign-in.

For example, in a SwiftUI app:

ContentView.swift
struct ContentView: View {
  @State var isAuthenticated: Bool

  private let redirectUri = "io.logto.app://callback"
  private let postLogoutRedirectUri = "io.logto.app://signed-out"

  init() {
    isAuthenticated = client.isAuthenticated
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Button("Sign Out") {
          Task { [self] in
            let error = await client.signOut(postLogoutRedirectUri: postLogoutRedirectUri)
            if let error = error {
              print(error)
              return
            }
            isAuthenticated = false
          }
        }
      } else {
        Button("Sign In") {
          Task { [self] in
            do {
              try await client.signInWithBrowser(redirectUri: redirectUri)
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // error occurred during sign in
            } catch {
              // other errors
            }
          }
        }
      }
    }
  }
}

注記:

You can also call client.signOut() without a post sign-out redirect URI. No Console configuration is needed in this case: the browser shows the Logto sign-out page, and the user returns to the app by dismissing it manually.
If no UI context is available, you can call client.clearCredentials() to clear the local credentials and revoke the refresh token. Note that this keeps the Logto session in the browser, so the next signInWithBrowser may silently sign the user back in through that session.

You can use client.signInWithBrowser(redirectUri:) to sign in the user and client.signOut() to sign out the user.

For example, in a SwiftUI app:

ContentView.swift
struct ContentView: View {
  @State var isAuthenticated: Bool

  init() {
    isAuthenticated = client.isAuthenticated
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Button("Sign Out") {
          Task { [self] in
            await client.signOut()
            isAuthenticated = false
          }
        }
      } else {
        Button("Sign In") {
          Task { [self] in
            do {
              try await client.signInWithBrowser(redirectUri: "io.logto://callback")
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // error occurred during sign in
            } catch {
              // other errors
            }
          }
        }
      }
    }
  }
}

チェックポイント: アプリケーションをテストする

これで、アプリケーションをテストできます：

アプリケーションを実行すると、サインインボタンが表示されます。
サインインボタンをクリックすると、SDK がサインインプロセスを初期化し、Logto のサインインページにリダイレクトされます。
サインインすると、アプリケーションに戻り、サインアウトボタンが表示されます。
サインアウトボタンをクリックして、トークンストレージをクリアし、サインアウトします。

OIDC コネクターを追加する

迅速なサインインを有効にし、ユーザーコンバージョンを向上させるために、アイデンティティプロバイダー (IdP) として iOS (Swift) を接続します。Logto ソーシャルコネクターは、いくつかのパラメーター入力を許可することで、この接続を数分で確立するのに役立ちます。

ソーシャルコネクターを追加するには、次の手順に従ってください：

Console > Connectors > Social Connectors に移動します。
「Add social connector」をクリックし、「OIDC」を選択します。
README ガイドに従い、必要なフィールドを完了し、設定をカスタマイズします。

注記:

インプレースコネクターガイドに従っている場合は、次のセクションをスキップできます。

Standard OIDC app を設定する

OIDC アプリの作成

このページを開いた時点で、接続したいソーシャルアイデンティティプロバイダーが決まっているはずです。最初に行うべきことは、そのアイデンティティプロバイダーが OIDC プロトコルをサポートしているかを確認することです。これは有効なコネクターを構成するための前提条件です。その後、アイデンティティプロバイダーの手順に従って、OIDC 認可用の関連アプリを登録・作成してください。

コネクターの構成

セキュリティ上の理由から「認可コード」グラントタイプのみをサポートしており、これは Logto のシナリオに完全に適合します。

clientId および clientSecret は、OIDC アプリの詳細ページで確認できます。

clientId：クライアント ID は、認可サーバーへの登録時にクライアントアプリケーションを識別する一意の識別子です。この ID は、認可サーバーがクライアントアプリケーションのアイデンティティを確認し、認可されたアクセストークンを特定のクライアントアプリケーションに関連付けるために使用されます。

clientSecret：クライアントシークレットは、登録時に認可サーバーからクライアントアプリケーションに発行される秘密鍵です。クライアントアプリケーションは、この秘密鍵を使用して、アクセストークンを要求する際に認可サーバーに対して自身を認証します。クライアントシークレットは機密情報と見なされ、常に安全に保管する必要があります。

tokenEndpointAuthMethod：トークンエンドポイント認証方式は、クライアントアプリケーションがアクセストークンを要求する際に認可サーバーに対して自身を認証するために使用されます。サポートされている方式を確認するには、OAuth 2.0 サービスプロバイダーの OpenID Connect ディスカバリエンドポイントで利用可能な token_endpoint_auth_methods_supported フィールドを参照するか、OAuth 2.0 サービスプロバイダーの関連ドキュメントを参照してください。

clientSecretJwtSigningAlgorithm (オプション)：tokenEndpointAuthMethod が client_secret_jwt の場合のみ必要です。クライアントシークレット JWT 署名アルゴリズムは、トークンリクエスト時にクライアントアプリケーションが認可サーバーに送信する JWT に署名するために使用されます。

scope：スコープパラメーターは、クライアントアプリケーションがアクセスを要求するリソースと権限のセットを指定するために使用されます。スコープパラメーターは通常、特定の権限を表す値のスペース区切りリストとして定義されます。たとえば、スコープ値が "read write" の場合、クライアントアプリケーションがユーザーデータの読み取りおよび書き込みアクセスを要求していることを示します。

authorizationEndpoint、tokenEndpoint、jwksUri および issuer は、OpenID プロバイダーの構成情報として見つけることができます。これらはソーシャルベンダーのドキュメントに記載されています。

authenticationEndpoint：このエンドポイントは認証 (Authentication) プロセスを開始するために使用されます。認証 (Authentication) プロセスは通常、ユーザーがログインし、クライアントアプリケーションにリソースへのアクセスを許可することを含みます。

tokenEndpoint：このエンドポイントは、クライアントアプリケーションがリクエストされたリソースにアクセスするために使用できる ID トークンを取得するために使用されます。クライアントアプリケーションは通常、グラントタイプと認可コードを含むリクエストをトークンエンドポイントに送信し、ID トークンを受け取ります。

jwksUri：これは、ソーシャルアイデンティティプロバイダー（略して IdP）の JSON Web Key Set (JWKS) を取得できる URL エンドポイントです。JWKS は、IdP が認証 (Authentication) プロセス中に発行する JSON Web Token (JWT) の署名および検証に使用する暗号鍵のセットです。jwksUri は、リライングパーティ (RP) が IdP によって署名された JWT の公開鍵を取得するために使用され、RP は IdP から受け取った JWT の真正性と完全性を検証できます。

issuer：これは、RP が IdP から受け取った JWT を検証するために使用する IdP の一意の識別子です。JWT には iss クレームとして含まれています（ID トークンは常に JWT です）。issuer の値は、IdP の認可サーバーの URL と一致する必要があり、RP が信頼する URI である必要があります。RP が JWT を受け取ると、iss クレームを確認して、それが信頼できる IdP によって発行されたものであり、RP で使用することを意図していることを確認します。

jwksUri と issuer を組み合わせることで、RP は認証 (Authentication) プロセス中にエンドユーザーのアイデンティティを安全に検証できます。jwksUri から取得した公開鍵を使用して、RP は IdP によって発行された JWT の真正性と完全性を検証できます。issuer の値により、RP は信頼できる IdP によって発行された JWT のみを受け入れ、JWT が RP で使用されることを保証します。

認証リクエストは常に必要なため、authRequestOptionalConfig でオプション設定をまとめて指定できます。詳細は OIDC 認証リクエストを参照してください。また、この設定に nonce がないことに気付くかもしれません。nonce は各リクエストごとに一意である必要があるため、生成はコード実装側で行っています。ご安心ください！前述の jwksUri と issuer も idTokenVerificationConfig に含まれています。

標準の OIDC プロトコルがインプリシットフローやハイブリッドフローもサポートしているのに、Logto コネクターが認可フローのみをサポートしている理由が気になるかもしれません。インプリシットフローやハイブリッドフローは認可フローよりもセキュリティが低いと判断されています。Logto はセキュリティを重視しているため、利便性がやや劣るものの、ユーザーに最高レベルのセキュリティを提供するために認可フローのみをサポートしています。

responseType および grantType は「認可コード」フローでのみ固定値となるため、オプション扱いとし、デフォルト値が自動的に設定されます。

注記:

すべてのフロータイプに対して、カスタマイズパラメーターを格納できるオプションの customConfig キーを用意しています。各ソーシャルアイデンティティプロバイダーは OIDC 標準プロトコルに独自のバリエーションを持つ場合があります。ご希望のソーシャルアイデンティティプロバイダーが OIDC 標準プロトコルに厳密に準拠している場合は、customConfig を気にする必要はありません。

設定タイプ

名前	型	必須
scope	string	True
clientId	string	True
clientSecret	string	True
authorizationEndpoint	string	True
tokenEndpoint	string	True
idTokenVerificationConfig	IdTokenVerificationConfig	True
authRequestOptionalConfig	AuthRequestOptionalConfig	False
customConfig	Record<string, string>	False

AuthRequestOptionalConfig のプロパティ	型	必須
responseType	string	False
tokenEndpoint	string	False
responseMode	string	False
display	string	False
prompt	string	False
maxAge	string	False
uiLocales	string	False
idTokenHint	string	False
loginHint	string	False
acrValues	string	False

IdTokenVerificationConfig のプロパティ	型	必須
jwksUri	string	True
issuer	string \| string[]	False
audience	string \| string[]	False
algorithms	string[]	False
clockTolerance	string \| number	False
crit	Record<string, string \| boolean>	False
currentDate	Date	False
maxTokenAge	string \| number	False
subject	string	False
typ	string	False

IdTokenVerificationConfig の詳細についてはこちらを参照してください。

一般設定

ここでは、アイデンティティプロバイダーへの接続を妨げることはありませんが、エンドユーザーの認証 (Authentication) 体験に影響を与える可能性のある一般的な設定を紹介します。

ログインページにソーシャルボタンを表示したい場合は、ソーシャルアイデンティティプロバイダーの名前とロゴ（ダークモードおよびライトモード）を設定できます。これにより、ユーザーがソーシャルログインオプションを認識しやすくなります。

アイデンティティプロバイダー名

各ソーシャルコネクターには、ユーザーアイデンティティを区別するための一意のアイデンティティプロバイダー (IdP) 名があります。一般的なコネクターは固定の IdP 名を使用しますが、カスタムコネクターでは一意の値が必要です。詳細は IdP 名についてをご覧ください。

プロフィール情報の同期

OIDC コネクターでは、ユーザー名やアバターなどのプロフィール情報の同期ポリシーを設定できます。次のいずれかを選択できます：

サインアップ時のみ同期：ユーザーが初めてサインインしたときにプロフィール情報を一度だけ取得します。
サインイン時に常に同期：ユーザーがサインインするたびにプロフィール情報を更新します。

サードパーティ API へのトークン保存（オプション）

アイデンティティプロバイダーの API にアクセスし、ユーザーの認可で操作（ソーシャルサインインまたはアカウント連携経由）を行いたい場合、Logto は特定の API スコープを取得し、トークンを保存する必要があります。

上記の手順に従い、scope フィールドに必要なスコープを追加します
Logto OIDC コネクターで API への永続的なトークン保存 を有効にします。Logto はアクセストークンを Secret Vault に安全に保存します。
標準 OAuth/OIDC アイデンティティプロバイダーの場合、リフレッシュトークンを取得するには offline_access スコープを含める必要があり、これによりユーザーへの同意プロンプトの繰り返しを防ぎます。

警告:

クライアントシークレットは安全に保管し、クライアントサイドのコードで絶対に公開しないでください。漏洩した場合は、アイデンティティプロバイダーのアプリ設定で直ちに新しいものを発行してください。

OIDC コネクターの活用

OIDC コネクターを作成し、アイデンティティプロバイダーと接続したら、エンドユーザーフローに組み込むことができます。ニーズに合ったオプションを選択してください：

Logto コンソールでサインイン & アカウント > サインアップとサインインに移動します。
ソーシャルサインイン セクションで OIDC コネクターを追加し、ユーザーがアイデンティティプロバイダーで認証 (Authentication) できるようにします。

ソーシャルサインイン体験について詳しく学ぶことができます。

Account API を利用して、アプリ内でサインイン済みユーザーがソーシャルアカウントを連携・解除できるカスタムアカウントセンターを構築できます。Account API チュートリアルを参照

ヒント:

ソーシャルサインインを有効にせず、アカウント連携や API アクセスのためだけに OIDC コネクターを有効にすることも可能です。

アイデンティティプロバイダー API へのアクセスと操作

アプリケーションは Secret Vault から保存されたアクセストークンを取得し、アイデンティティプロバイダーの API を呼び出してバックエンドタスクを自動化できます。具体的な機能はアイデンティティプロバイダーと要求したスコープによって異なります。API アクセス用の保存トークン取得ガイドを参照してください。

ユーザーがソーシャルアカウントを連携した後、管理者は Logto コンソールでその接続を管理できます：

Logto コンソール > ユーザー管理に移動し、ユーザーのプロフィールを開きます。
ソーシャル接続 の下でアイデンティティプロバイダー項目を見つけ、管理をクリックします。
このページで管理者はユーザーのソーシャル接続を管理し、ソーシャルアカウントから付与・同期されたすべてのプロフィール情報やアクセストークンの状態を確認できます。

注記:

一部のアイデンティティプロバイダーのアクセストークンレスポンスには、特定のスコープ情報が含まれていない場合があります。そのため、Logto ではユーザーが付与した権限リストを直接表示できません。ただし、ユーザーが認可時に要求されたスコープに同意していれば、アプリケーションは OIDC API へのアクセス時に対応する権限を持ちます。

設定を保存する

Logto コネクター設定エリアで必要な値をすべて記入したことを確認してください。「保存して完了」または「変更を保存」をクリックすると、OIDC コネクターが利用可能になります。

ソーシャルコネクターを正常に作成したら、サインイン体験で「OIDC で続行」ボタンとして有効にすることができます。

Console > サインイン体験 > サインアップとサインインに移動します。
（オプション）ソーシャルログインのみが必要な場合は、サインアップ識別子に「該当なし」を選択します。
設定済みの OIDC コネクターを「ソーシャルサインイン」セクションに追加します。

テストと検証

iOS (Swift) アプリに戻ります。これで OIDC を使用してサインインできるはずです。お楽しみください！

さらなる読み物

エンドユーザーフロー：Logto は、MFA やエンタープライズシングルサインオン (SSO) を含む即時使用可能な認証 (Authentication) フローを提供し、アカウント設定、セキュリティ検証、マルチテナント体験の柔軟な実装のための強力な API を備えています。

認可 (Authorization)：認可 (Authorization) は、ユーザーが認証 (Authentication) された後に行えるアクションやアクセスできるリソースを定義します。ネイティブおよびシングルページアプリケーションの API を保護し、ロールベースのアクセス制御 (RBAC) を実装する方法を探ります。

組織 (Organizations)：特にマルチテナント SaaS や B2B アプリで効果的な組織機能は、テナントの作成、メンバー管理、組織レベルの RBAC、およびジャストインタイムプロビジョニングを可能にします。

顧客 IAM シリーズ：顧客（または消費者）アイデンティティとアクセス管理に関する連続ブログ投稿で、101 から高度なトピックまでを網羅しています。

Logto でアプリケーションを作成する​

iOS (Swift) SDK を統合する​

Logto SDK を依存関係として追加する​

Carthage​

CocoaPods​

LogtoClient を初期化する​

サインイン​

リダイレクトベースのサインインについて​

Configure redirect URI​

Use Universal Links instead of a custom scheme?​

Sign-in and sign-out​

チェックポイント: アプリケーションをテストする​

OIDC コネクターを追加する​

Standard OIDC app を設定する​

OIDC アプリの作成​

コネクターの構成​

設定タイプ​

一般設定​

ソーシャルボタン名とロゴ​

アイデンティティプロバイダー名​

プロフィール情報の同期​

サードパーティ API へのトークン保存（オプション）​

OIDC コネクターの活用​

ソーシャルサインインボタンの有効化​

ソーシャルアカウントの連携・解除​

アイデンティティプロバイダー API へのアクセスと操作​

ユーザーのソーシャルアイデンティティ管理​

設定を保存する​

サインイン体験で OIDC コネクターを有効にする​

テストと検証​

さらなる読み物​