Logto は、モダンなアプリや SaaS 製品向けに設計された Auth0 の代替です。 Cloud と オープンソース の両方のサービスを提供し、アイデンティティと管理 (IAM) システムを迅速に立ち上げるのに役立ちます。認証 (Authentication)、認可 (Authorization)、マルチテナント管理を すべて一つに まとめて楽しんでください。
Logto Cloud で無料の開発テナントから始めることをお勧めします。これにより、すべての機能を簡単に探索できます。
この記事では、Go と Logto を使用して、Microsoft Entra ID SAML enterprise SSO サインイン体験(ユーザー認証 (Authentication))を迅速に構築する手順を説明します。
前提条件
- 稼働中の Logto インスタンス。紹介ページ をチェックして始めてください。
- Go の基本的な知識。
- 使用可能な Microsoft Entra ID SAML enterprise SSO アカウント。
Create an application in Logto
Logto は OpenID Connect (OIDC) 認証 (Authentication) と OAuth 2.0 認可 (Authorization) に基づいています。これは、複数のアプリケーション間でのフェデレーテッドアイデンティティ管理をサポートし、一般的にシングルサインオン (SSO) と呼ばれます。
あなたの Traditional web アプリケーションを作成するには、次の手順に従ってください:
- Logto コンソール を開きます。「Get started」セクションで、「View all」リンクをクリックしてアプリケーションフレームワークのリストを開きます。あるいは、Logto Console > Applications に移動し、「Create application」ボタンをクリックします。
- 開いたモーダルで、左側のクイックフィルターチェックボックスを使用して、利用可能なすべての "Traditional web" フレームワークをフィルタリングするか、"Traditional web" セクションをクリックします。"Go" フレームワークカードをクリックして、アプリケーションの作成を開始します。
- アプリケーション名を入力します。例:「Bookstore」と入力し、「Create application」をクリックします。
🎉 タダーン!Logto で最初のアプリケーションを作成しました。詳細な統合ガイドを含むお祝いページが表示されます。ガイドに従って、アプリケーションでの体験を確認してください。
Integrate Go SDK
- 以下のデモは Gin Web Framework を基盤としています。同じ手順で他のフレームワークにも Logto を統合できます。
- Go のサンプルプロジェクトは Go SDK リポジトリ で利用できます。
インストール
プロジェクトのルートディレクトリで次のコマンドを実行します:
# 事前定義された値や型へアクセスするためのコアパッケージをインストール
go get github.com/logto-io/go/v2/core
# Logto と連携するためのクライアントパッケージをインストール
go get github.com/logto-io/go/v2/client
アプリケーションコードに github.com/logto-io/go/v2/core および github.com/logto-io/go/v2/client パッケージを追加します:
// main.go
package main
import (
"github.com/gin-gonic/gin"
// 依存関係を追加
"github.com/logto-io/go/v2/core"
"github.com/logto-io/go/v2/client"
)
func main() {
router := gin.Default()
router.GET("/", func(c *gin.Context) {
c.String(200, "Hello Logto!")
})
router.Run(":3000")
}
セッションストレージを作成する
従来の Web アプリケーションでは、ユーザーの認証 (Authentication) 情報はユーザーセッションに保存されます。
Logto SDK では Storage インターフェースが提供されており、Web フレームワークに合わせて Storage アダプターを実装することで、Logto SDK がユーザーの認証 (Authentication) 情報をセッションに保存できるようになります。
Logto によって保存されるユーザー認証 (Authentication) 情報はクッキーのサイズ制限を超える可能性があるため、クッキー ベースのセッションの使用は推奨しません。 この例ではメモリ ベースのセッションを使用しています。実運用では必要に応じて Redis や MongoDB などの技術を使ってセッションを保存できます。
Logto SDK の Storage 型は次のとおりです:
package client
type Storage interface {
GetItem(key string) string
SetItem(key, value string)
}
github.com/gin-contrib/sessions ミドルウェアを例として、このプロセスを説明します。
ミドルウェアをアプリケーションに適用することで、ルートハンドラー内でユーザーリクエストコンテキストからユーザーセッションを取得できます:
package main
import (
"github.com/gin-contrib/sessions"
"github.com/gin-contrib/sessions/memstore"
"github.com/gin-gonic/gin"
"github.com/logto-io/go/v2/client"
)
func main() {
router := gin.Default()
// この例ではメモリ ベースのセッションを使用します
store := memstore.NewStore([]byte("your session secret"))
router.Use(sessions.Sessions("logto-session", store))
router.GET("/", func(ctx *gin.Context) {
// ユーザーセッションを取得
session := sessions.Default(ctx)
// ...
ctx.String(200, "Hello Logto!")
})
router.Run(":3000")
}
session_storage.go ファイルを作成し、SessionStorage を定義して Logto SDK の Storage インターフェースを実装します:
package main
import (
"github.com/gin-contrib/sessions"
)
type SessionStorage struct {
session sessions.Session
}
func (storage *SessionStorage) GetItem(key string) string {
value := storage.session.Get(key)
if value == nil {
return ""
}
return value.(string)
}
func (storage *SessionStorage) SetItem(key, value string) {
storage.session.Set(key, value)
storage.session.Save()
}
これで、ルートハンドラー内で Logto 用のセッションストレージを作成できます:
session := sessions.Default(ctx)
sessionStorage := &SessionStorage{session: session}
LogtoClient を初期化する
まず、Logto の設定を作成します:
func main() {
// ...
logtoConfig := &client.LogtoConfig{
Endpoint: "<your-logto-endpoint>", // 例: http://localhost:3001
AppId: "<your-application-id>",
AppSecret: "<your-application-secret>",
}
// ...
}
「App Secret」は管理コンソールのアプリケーション詳細ページから見つけてコピーできます:

次に、上記の Logto 設定を使用して、各ユーザーリクエストに対して LogtoClient を作成できます:
func main() {
// ...
router.GET("/", func(ctx *gin.Context) {
// LogtoClient を作成
session := sessions.Default(ctx)
logtoClient := client.NewLogtoClient(
logtoConfig,
&SessionStorage{session: session},
)
// Logto を使用してホームページのコンテンツを制御
authState := "このウェブサイトにログインしていません。 :("
if logtoClient.IsAuthenticated() {
authState = "このウェブサイトにログインしています! :)"
}
homePage := `<h1>Hello Logto</h1>` +
"<div>" + authState + "</div>"
ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
})
// ...
}
サインインルートを実装する
リダイレクト URI が設定された後、サインインリクエストを処理するために sign-in ルートを追加し、ホームページにサインインリンクも追加します:
func main() {
// ...
// ホームページにサインインリクエストを実行するリンクを追加
router.GET("/", func(ctx *gin.Context) {
// ...
homePage := `<h1>Hello Logto</h1>` +
"<div>" + authState + "</div>" +
// リンクを追加
`<div><a href="/sign-in">Sign In</a></div>`
ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
})
// サインインリクエストを処理するためのルートを追加
router.GET("/sign-in", func(ctx *gin.Context) {
session := sessions.Default(ctx)
logtoClient := client.NewLogtoClient(
logtoConfig,
&SessionStorage{session: session},
)
// サインインリクエストは Logto によって処理されます。
// ユーザーはサインイン後にリダイレクト URI にリダイレクトされます。
signInUri, err := logtoClient.SignIn("http://localhost:3000/callback")
if err != nil {
ctx.String(http.StatusInternalServerError, err.Error())
return
}
// ユーザーを Logto サインインページにリダイレクトします。
ctx.Redirect(http.StatusTemporaryRedirect, signInUri)
})
// ...
}
これで、ユーザーが http://localhost:3000/sign-in にアクセスすると、Logto サインインページにリダイレクトされます。
コールバックルートを実装する
ユーザーが Logto のサインインページで正常にサインインすると、Logto はユーザーをリダイレクト URI にリダイレクトします。
リダイレクト URI が http://localhost:3000/callback であるため、サインイン後のコールバックを処理するために /callback ルートを追加します。
func main() {
// ...
// サインインコールバックリクエストを処理するためのルートを追加
router.GET("/callback", func(ctx *gin.Context) {
session := sessions.Default(ctx)
logtoClient := client.NewLogtoClient(
logtoConfig,
&SessionStorage{session: session},
)
// サインインコールバックリクエストは Logto によって処理されます
err := logtoClient.HandleSignInCallback(ctx.Request)
if err != nil {
ctx.String(http.StatusInternalServerError, err.Error())
return
}
// 開発者が指定したページにジャンプします。
// この例では、ユーザーをホームページに戻します。
ctx.Redirect(http.StatusTemporaryRedirect, "/")
})
// ...
}
サインアウトルートを実装する
ユーザーがサインアウトすると、Logto はユーザーをポストサインアウトリダイレクト URI にリダイレクトします。
次に、sign-out ルートを追加してサインアウトリクエストを処理し、ホームページにサインアウトリンクを追加しましょう:
func main() {
// ...
// ホームページにサインアウトリクエストを実行するリンクを追加
router.GET("/", func(ctx *gin.Context) {
// ...
homePage := `<h1>Hello Logto</h1>` +
"<div>" + authState + "</div>" +
`<div><a href="/sign-in">Sign In</a></div>` +
// リンクを追加
`<div><a href="/sign-out">Sign Out</a></div>`
ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
})
// サインアウトリクエストを処理するルートを追加
router.GET("/sign-out", func(ctx *gin.Context) {
session := sessions.Default(ctx)
logtoClient := client.NewLogtoClient(
logtoConfig,
&SessionStorage{session: session},
)
// サインアウトリクエストは Logto によって処理されます。
// サインアウト後、ユーザーはポストサインアウトリダイレクト URI にリダイレクトされます。
signOutUri, signOutErr := logtoClient.SignOut("http://localhost:3000")
if signOutErr != nil {
ctx.String(http.StatusOK, signOutErr.Error())
return
}
ctx.Redirect(http.StatusTemporaryRedirect, signOutUri)
})
// ...
}
ユーザーがサインアウトリクエストを行った後、Logto はセッション内のすべてのユーザー認証情報をクリアします。
チェックポイント: アプリケーションをテストする
これで、アプリケーションをテストできます:
- アプリケーションを実行すると、サインインボタンが表示されます。
- サインインボタンをクリックすると、SDK がサインインプロセスを初期化し、Logto のサインインページにリダイレクトされます。
- サインインすると、アプリケーションに戻り、サインアウトボタンが表示されます。
- サインアウトボタンをクリックして、トークンストレージをクリアし、サインアウトします。
Add Microsoft Entra ID SAML enterprise SSO connector
アクセス管理を簡素化し、大規模なクライアント向けにエンタープライズレベルの保護を得るために、Go をフェデレーテッドアイデンティティプロバイダーとして接続します。Logto エンタープライズシングルサインオン (SSO) コネクターは、いくつかのパラメーター入力を許可することで、この接続を数分で確立するのに役立ちます。
エンタープライズ SSO コネクターを追加するには、次の手順に従ってください:
- Logto コンソール > エンタープライズ SSO に移動します。
- 「エンタープライズコネクターを追加」ボタンをクリックし、SSO プロバイダーのタイプを選択します。Microsoft Entra ID (Azure AD)、Google Workspace、Okta の事前構築されたコネクターから選択するか、標準の OpenID Connect (OIDC) または SAML プロトコルを使用してカスタム SSO 接続を作成します。
- 一意の名前を指定します(例:Acme Company の SSO サインイン)。
- 「接続」タブで IdP と接続を構成します。各コネクタータイプのガイドを上記で確認してください。
- 「体験 (Experience)」タブで SSO 体験と企業の メールドメイン をカスタマイズします。SSO 対応のメールドメインでサインインするユーザーは、SSO 認証にリダイレクトされます。
- 変更を保存します。
Set up Azure AD SSO application
ステップ 1: Azure AD SSO アプリケーションの作成
Azure AD 側で SSO アプリケーションを作成することで、Azure AD SSO 統合を開始します。
- Azure ポータル にアクセスし、管理者としてサインインします。
Microsoft Entra IDサービスを選択します。- サイドメニューを使用して
Enterprise applicationsに移動します。New applicationをクリックし、Create your own applicationを選択します。
- アプリケーション名を入力し、
Integrate any other application you don't find in the gallery (Non-gallery)を選択します。 Setup single sign-on>SAMLを選択します。
- 指示に従って、最初のステップとして、Logto によって提供される以下の情報を使用して基本的な SAML 設定を入力する必要があります。
- Audience URI(SP Entity ID): これは、IdP への認証リクエスト中に SP の EntityId として機能し、Logto サービスのグローバルに一意の識別子として表されます。この識別子は、IdP と Logto 間で SAML アサーションやその他の認証関連データを安全に交換するために重要です。
- ACS URL: Assertion Consumer Service (ACS) URL は、POST リクエストで SAML アサーションが送信される場所です。この URL は、IdP が SAML アサーションを Logto に送信するために使用されます。これは、Logto がユーザーのアイデンティティ情報を含む SAML 応答を受信し消費することを期待するコールバック URL として機能します。
Save をクリックして続行します。
ステップ 2: Logto で SAML SSO を構成する
SAML SSO 統合を機能させるには、IdP メタデータを Logto に戻す必要があります。Logto 側に戻り、Azure AD SSO コネクターの Connection タブに移動しましょう。
Logto は、IdP メタデータを構成するための 3 つの異なる方法を提供しています。最も簡単な方法は、Azure AD SSO アプリケーションの metadata URL を提供することです。
Azure AD SSO アプリケーションの SAML Certificates section から App Federation Metadata Url をコピーし、Logto の Metadata URL フィールドに貼り付けます。
Logto は URL からメタデータを取得し、SAML SSO 統合を自動的に構成します。
ステップ 3: ユーザー属性マッピングの設定
Logto は、IdP から返されるユーザー属性を Logto のユーザー属性にマッピングする柔軟な方法を提供します。Logto はデフォルトで次のユーザー属性を IdP から同期します:
- id: ユーザーの一意の識別子。Logto は SAML レスポンスから
nameIDクレームを読み取り、ユーザーの SSO アイデンティティ ID として使用します。 - email: ユーザーのメールアドレス。Logto はデフォルトで SAML レスポンスから
emailクレームを読み取り、ユーザーのプライマリメールとして使用します。 - name: ユーザーの名前。
ユーザー属性のマッピングロジックは、Azure AD 側または Logto 側のいずれかで管理できます。
-
AzureAD ユーザー属性を Logto ユーザー属性に Logto 側でマッピングします。
Azure AD SSO アプリケーションの
Attributes & Claimsセクションにアクセスします。次の属性名(名前空間プレフィックス付き)をコピーして、Logto の対応するフィールドに貼り付けます。
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddresshttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/name(推奨:この属性値マップをuser.displaynameに更新して、より良いユーザー体験を提供します)
-
AzureAD ユーザー属性を AzureAD 側で Logto ユーザー属性にマッピングします。
Azure AD SSO アプリケーションの
Attributes & Claimsセクションにアクセスします。Editをクリックし、Logto ユーザー属性設定に基づいてAdditional claimsフィールドを更新します:- Logto ユーザー属性設定に基づいてクレーム名の値を更新します。
- 名前空間プレフィックスを削除します。
Saveをクリックして続行します。
次の設定で終了する必要があります:
Azure AD 側で追加のユーザー属性を指定することもできます。Logto は、ユーザーの sso_identity フィールドの下に IdP から返された元のユーザー属性の記録を保持します。
ステップ 4: Azure AD SSO アプリケーションにユーザーを割り当てる
Azure AD SSO アプリケーションの Users and groups セクションにアクセスします。Add user/group をクリックして、Azure AD SSO アプリケーションにユーザーを割り当てます。Azure AD SSO アプリケーションに割り当てられたユーザーのみが、Azure AD SSO コネクターを通じて認証 (Authentication) できます。
ステップ 5: メールドメインの設定と SSO コネクターの有効化
Logto のコネクター SSO 体験 タブで、あなたの組織の メールドメイン を提供してください。これにより、これらのユーザーに対する認証 (Authentication) 方法として SSO コネクターが有効になります。
指定されたドメインのメールアドレスを持つユーザーは、唯一の認証 (Authentication) 方法として SAML SSO コネクターを使用するようにリダイレクトされます。
Azure AD SSO 統合の詳細については、Azure AD の公式 ドキュメント を確認してください。
オプション: 署名付き認証リクエスト (Authentication request) を強制する
Microsoft Entra ID では、署名付き SAML 認証リクエスト (Authentication request) を要求できます。Logto でこれを利用する場合、サインインの中断を避けるために次の順序で操作してください:
- Logto コネクターの
Connectionタブで、Request signing certificate の下にある Generate new key をクリックし、アクティブキーの証明書をダウンロードします。 - Entra ID アプリケーションのシングルサインオン設定で、証明書を Verification certificates の下にアップロードします。詳細は 署名付き SAML 認証リクエスト (Authentication request) の強制 を参照してください。
- Logto に戻り、コネクターで Sign authentication request を有効にして保存します。
- Entra ID で Require verification certificates をチェックし、サインインフローをテストします。
Entra ID は RSA-SHA256(Logto のデフォルトアルゴリズム)で署名されたリクエスト (Authentication request) のみを検証し、SP 発行のサインインリクエスト (Authentication request) に対してこの要件を強制します。セットアップ全体や証明書ローテーションの流れについては、SAML 認証リクエスト (Authentication request) に署名する を参照してください。
Save your configuration
Logto コネクター設定エリアで必要な値をすべて記入したことを確認してください。「保存して完了」または「変更を保存」をクリックすると、Microsoft Entra ID SAML enterprise SSO コネクターが利用可能になります。
Enable Microsoft Entra ID SAML enterprise SSO connector in Sign-in Experience
エンタープライズコネクターを個別に設定する必要はありません。Logto は、ワンクリックでアプリケーションに SSO 統合を簡素化します。
- 移動先: Console > サインイン体験 > サインアップとサインイン。
- 「エンタープライズシングルサインオン (SSO)」トグルを有効にします。
- 変更を保存します。
有効にすると、サインインページに「シングルサインオン (SSO)」ボタンが表示されます。SSO が有効なメールドメインを持つエンタープライズユーザーは、エンタープライズアイデンティティプロバイダー (IdP) を使用してサービスにアクセスできます。
SP 主導の SSO や IdP 主導の SSO を含む SSO ユーザー体験について詳しくは、ユーザーフロー: エンタープライズ SSO を参照してください。
Testing and Validation
Go アプリに戻ります。これで Microsoft Entra ID SAML enterprise SSO を使用してサインインできるはずです。お楽しみください!
Further readings
エンドユーザーフロー:Logto は、MFA やエンタープライズシングルサインオン (SSO) を含む即時使用可能な認証 (Authentication) フローを提供し、アカウント設定、セキュリティ検証、マルチテナント体験の柔軟な実装のための強力な API を備えています。
認可 (Authorization):認可 (Authorization) は、ユーザーが認証 (Authentication) された後に行えるアクションやアクセスできるリソースを定義します。ネイティブおよびシングルページアプリケーションの API を保護し、ロールベースのアクセス制御 (RBAC) を実装する方法を探ります。
組織 (Organizations):特にマルチテナント SaaS や B2B アプリで効果的な組織機能は、テナントの作成、メンバー管理、組織レベルの RBAC、およびジャストインタイムプロビジョニングを可能にします。
顧客 IAM シリーズ:顧客(または消費者)アイデンティティとアクセス管理に関する連続ブログ投稿で、101 から高度なトピックまでを網羅しています。