Lark と Guance(SaaS)の OIDC 設定について¶
本ドキュメントには次の 2 つの部分があります。
- Lark 統合プラットフォーム(Anycross)と Guance の連携について
- Lark ネイティブプラットフォームと Guance の連携について
アプリの作成方法(Lark 側)に応じて、該当する章の設定手順と JSON テンプレートを使用してください。
1. Lark 統合プラットフォーム(Anycross)連携手順¶
ユースケース¶
Lark 統合プラットフォーム(https://anycross.feishu.cn)で作成したアプリと Guance(SaaS)を OIDC で SSO 連携する場合に適用します。
基本ルール¶
- Lark アプリの Token 認証方式が
client_secret_basicの場合:Guance の UI でclientId/clientSecretを直接入力できます。JSON テンプレートのインポートは不要です(推奨)。 - Token 認証方式が
client_secret_postの場合:Guance の「非 OIDC 標準設定」で JSON テンプレートをインポートする必要があります。
お客様が準備する情報¶
| 情報項目 | 説明 |
|---|---|
| clientId | アプリのクライアント ID(App ID) |
| clientSecret | アプリのクライアントシークレット(App Secret) |
| scope | 要求する権限スコープ。アプリで開通済みの権限および実際の用途と一致させる必要があります |
| claimMapping | アカウント情報のマッピング。実際の userinfo フィールドと一致させる必要があります |
claimMapping の例:
説明:このテンプレートでは、ログイン用メールアドレスを enterprise_email にマッピングします。アプリにこのフィールドの取得権限があり、対象ユーザーの実際の userinfo に有効なメールアドレスが返されることを確認してください。このフィールドが必ず存在するとは想定できません。別のメールフィールドを使用する場合は、それがアカウントの識別要件を満たすことを確認してから claimMapping.email を調整してください。
現在のログインでは email、name、username、mobile のマッピングが読み取られます。このうち有効なメールアドレスが必須です。exterId マッピングはこのログインフローでは使用されないため、テンプレートに記入する必要はありません。
Lark 統合プラットフォーム側の確認項目¶
- App ID、App Secret が有効であることを確認します。
- サービスディスカバリの URL(テンプレートのフィールド名は
wellKnowURL)を取得します。 - 認可モードは
authorization_codeである必要があります。テンプレートはopenid、profile、emailを起点としているため、サービスディスカバリ情報と実際に開通している権限に照らして確認してください。 - 携帯電話番号やオフライン認可が必要な場合は、アプリが対応する
phone、offline_accessスコープのリクエストをサポートし、許可されていることを確認してから、必要に応じてテンプレートに追加してください。これらの 2 つのスコープをすべてのログインシナリオで必須にしないでください。 - Token 取得時の認証方式(
client_secret_basicまたはclient_secret_post)を確認します。
Guance 側の設定¶
シナリオ 1 — client_secret_basic(推奨)
- Guance にログインし、SSO 設定 → OIDC ページでサービスディスカバリの URL、
clientId、clientSecretを入力します。 - 保存して SSO ログインをテストします。
シナリオ 2 — client_secret_post
- Guance 公式の「OIDC 非標準設定」の章を参照し、以下の JSON テンプレートを使用して
clientId、clientSecret、wellKnowURLを入力します。 - Guance の OIDC 非標準設定ページでこの JSON テンプレートをインポートして保存し、SSO ログインをテストします。
JSON テンプレート(client_secret_post シナリオ限定)¶
{
"scope": ["openid","profile","email"],
"authSet": {
"url": "",
"verify": true,
"paramMapping": {
"scope": "$scope",
"state": "$state",
"client_id": "$client_id",
"redirect_uri": "$redirect_uri",
"response_type": "$response_type"
}
},
"clientId": "<填写 App ID>",
"clientSecret": "<填写 App Secret>",
"modeType": "expert",
"grantType": "authorization_code",
"sslVerify": true,
"getTokenSet": {
"url": "",
"method": "post",
"verify": true,
"authMethod": "none",
"paramMapping": {
"code": "$code",
"state": "$state",
"grant_type": "$grant_type",
"redirect_uri": "$redirect_uri",
"client_id": "$client_id",
"client_secret": "$client_secret"
}
},
"wellKnowURL": "<填写飞书服务发现地址>",
"claimMapping": {
"email": "enterprise_email",
"mobile": "mobile",
"username": "email"
},
"getUserInfoSet": {
"url": "",
"method": "get",
"source": "origin",
"authMethod": "bearer",
"paramMapping": {},
"responseInfoPath": ""
},
"verifyTokenSet": {"url": "", "keys": [], "method": "get", "verify": true}
}
テンプレートの入力について:clientId、clientSecret、wellKnowURL を入力し、scope と claimMapping を確認します。各 API の url フィールドが空の場合は、サービスディスカバリ情報から API のエンドポイントを特定します。
2. Lark ネイティブプラットフォーム連携手順¶
Lark ネイティブプラットフォームで作成したアプリと Guance(SaaS)を OIDC で連携する場合に適用します。この節の設定を「統合プラットフォーム」の設定と混用しないでください。
非互換のポイントと対応理由¶
- Lark ネイティブプラットフォームは、Code を Token と交換する際に Basic 認証をサポートしておらず、
client_secret_post(POST body でのパラメータ送信)のみサポートします。 - Lark が返すユーザー情報には
dataのネスト層が含まれるため、テンプレートのresponseInfoPathでdataを指定する必要があります。
お客様が準備する情報¶
| 情報項目 | 説明 |
|---|---|
| clientId | App ID |
| clientSecret | App Secret |
| scope | 権限リストの例。Lark 側で実際に開通している権限および実際の用途と一致させる必要があります |
| claimMapping | アカウントのマッピング。実際の userinfo フィールドと一致させる必要があります |
claimMapping の例:
scope リストの例(Lark 側で実際に開通している権限と必ず一致させてください):
Lark 側の確認項目¶
client_id(App ID)とclient_secret(App Secret)が正しいことを確認します。- 権限管理で、テンプレートに記載された
scopeの権限が開通済みで、アプリが公開済みであることを確認します。 - コールバック URL の登録:Guance がコールバック URL を生成するため、その URL を Lark アプリのコールバック URL に設定して公開する必要があります。
Guance 側の設定とコールバック設定¶
- Guance の OIDC 非標準設定ページで以下のテンプレートを使用し、
clientIdとclientSecretを入力して、実際に開通している権限とアカウントフィールドのマッピングを確認します。 getUserInfoSet.responseInfoPathがdata(Lark のレスポンス構造に適合)であることを確認します。- テンプレートをインポートして保存し、Guance が生成したコールバック URL をコピーして、Lark アプリの開発設定 → コールバック URL に貼り付け、アプリを公開します。
- SSO ログインをテストします。
JSON テンプレート(Lark ネイティブプラットフォーム専用)¶
{
"scope": [
"component:user_profile",
"contact:user.employee_id:readonly",
"contact:user.email:readonly"
],
"authSet": {
"url": "https://accounts.feishu.cn/open-apis/authen/v1/authorize",
"verify": true,
"paramMapping": {
"scope": "$scope",
"state": "$state",
"client_id": "$client_id",
"redirect_uri": "$redirect_uri",
"response_type": "$response_type"
}
},
"clientId": "<填写 App ID>",
"clientSecret": "<填写 App Secret>",
"modeType": "expert",
"grantType": "authorization_code",
"sslVerify": true,
"getTokenSet": {
"url": "https://open.feishu.cn/open-apis/authen/v2/oauth/token",
"method": "post",
"verify": true,
"authMethod": "none",
"paramMapping": {
"code": "$code",
"state": "$state",
"grant_type": "$grant_type",
"redirect_uri": "$redirect_uri",
"client_id": "$client_id",
"client_secret": "$client_secret"
}
},
"wellKnowURL": "",
"claimMapping": {
"email": "enterprise_email",
"mobile": "mobile",
"username": "email"
},
"getUserInfoSet": {
"url": "https://open.feishu.cn/open-apis/authen/v1/user_info",
"method": "get",
"source": "origin",
"authMethod": "bearer",
"paramMapping": {},
"responseInfoPath": "data"
},
"verifyTokenSet": {"url": "", "keys": [], "method": "get", "verify": true}
}
テンプレートの説明:clientId、clientSecret を入力したら、scope と実際に返される claimMapping.email フィールドを確認します。getTokenSet は POST body でクライアントの認証情報を送信し、responseInfoPath=data でユーザー情報を取得します。これらは接続する API のプロトコルおよびレスポンス構造と一致させる必要があります。
よくある質問とトラブルシューティング¶
問題 1:コールバック URL が無効(エラーコード:20029)¶
現象:SSO ログイン時に redirect_uri が無効であると表示されます。
対処:Guance の SSO 設定ページからシステム生成のコールバック URL をコピーし(手動で変更しない)、Lark アプリのコールバック URL 設定に貼り付けて公開します。その後、Guance で設定を更新して再試行します。
問題 2:認証失敗(エラー:「sso アカウントのメールアドレスが見つかりません」)¶
現象:ログイン時に SSO アカウントのメールアドレスが見つからないというエラーが表示されます。
対処:Lark が返したユーザー情報(エラーに含まれる trace_id を使用)を確認し、getUserInfoSet.responseInfoPath の設定を確認します。
- ユーザー情報が
dataのネスト層にある場合は、responseInfoPath = "data"のままにします。 - レスポンスがフラットな構造の場合は、
responseInfoPath = ""(空文字列)に設定します。 - その層を取得した後に、
claimMapping.emailが指すフィールドが実際に存在し、有効なメールアドレスであることを確認します。 - メールアドレスフィールドが返されない場合は、アプリの権限、ユーザーの認可、ユーザーのメールアドレス情報を確認します。
responseInfoPathの変更だけではメールアドレスフィールドの欠落は解決できません。
変更後にテンプレートを再インポートしてテストします。
問題 3:権限不足(Scope の設定異常)¶
対処:Lark アプリでテンプレートに記載された scope の権限が開通済みで、アプリが公開されていることを確認します。JSON テンプレートの scope リストが Lark 側と完全に一致していることを確認し、再インポートして保存します。