独自のOAuth 2.0プロバイダ経由での認証

この翻訳はAIによって生成されていますので、ご自身の判断でご利用ください。

動作の仕組み

OAuth 2.0プロトコルを使用して、ソーシャルネットワークを通じたユーザー認証を追加できます。認証ウィジェットにソーシャルネットワーク用のボタンを有効にするには、パブリッシャーアカウントでプロバイダーの詳細を指定してください。

認証フロー

  %%{init: {'themeVariables': { 'noteBkgColor': 'transparent', 'noteBorderColor': 'transparent' }}}%%
sequenceDiagram
    actor User as User
    participant TP as 3rd party
    participant XL as Xsolla Login
    participant OP as Partner OAuth2 Server
    User->>TP: Clicks login button
    TP->>XL: Calls Auth via social network (Xsolla Login API)
    XL->>OP: Calls partner's Authorization URL
    alt Success
        OP-->>XL: Sends authorization code to https://login.xsolla.com/api/social/callback
    else Dependency service unavailable
        OP-->>XL: Sends "Dependency service unavailable" error. Error code = "010-035"
    end
    XL->>OP: Calls partner's Token URL to exchange authorization code to access token
    alt Success
        OP-->>XL: Sends access token
    else Error getting token
        OP-->>XL: Sends "Error occurred while getting OAuth 2.0 Access token" error. Error code = "010-015"
    end
    XL->>OP: Calls partner's Your info URL to get user data
    alt Success
        OP-->>XL: Sends user data
    else Error getting profile
        OP-->>XL: Sends "Failed to get social profile" error. Error code = "010-036"
    end
    XL-->>TP: Returns Xsolla Login token
    TP-->>User: User is authenticated

ユーザーが認証ウィジェットの Log in with [Your Platform] ボタンをクリックします。
ユーザーはログインまたは同意ページにリダイレクトされます（アドレスは設定の認証URLフィールドに指定されています）。
ユーザーが認証情報を入力し、システムでアクセスを承認します。
システムが認証コードを持ってユーザーをエクソーラにリダイレクトします。
エクソーラがコードをアクセストークンと交換するためにシステムに連絡します（アドレスは設定のトークンURLフィールドに指定されています）。
エクソーラがアクセストークンを使用してシステムからユーザーのプロファイルデータ（ID、メールなど）を取得します（アドレスは設定のYour info URLフィールドに指定されています）。
ユーザーはログインされ、認証されたエクソーラユーザーとしてアプリケーションに戻ります。

リターンユーザーフロー

ユーザーが認証ウィジェットの Log in with [Your Platform] ボタンをクリックします。
ユーザーはログインまたは同意ページにリダイレクトされます（アドレスは設定の認証URLフィールドに指定されています）。
システムがアクティブなセッションを認識し、認証情報画面をスキップします。システムが毎回再認証を要求する場合、ユーザーは再びログインフォームを表示します。
システムがユーザーが以前に要求されたスコープを許可したかどうかを確認します。同意が既に与えられており、取り消されていない場合、同意画面はスキップされます。
システムが認証コードを持ってユーザーをエクソーラにリダイレクトします。
エクソーラがコードをアクセストークンと交換するためにシステムに連絡します（アドレスは設定のトークンURLフィールドに指定されています）。
エクソーラがアクセストークンを使用してシステムからユーザーの現在のプロファイルデータを取得します（アドレスは設定のYour info URLフィールドに指定されています）。
ユーザーはログインされ、アプリケーションに戻ります。通常、このフローは数秒で完了し、ユーザーからの目に見える操作は必要ありません。

認証失敗

認証URLが利用できない（エラー 010-035）

ユーザーが認証ウィジェットの Log in with [Your Platform] ボタンをクリックします。
ユーザーはログインまたは同意ページにリダイレクトされます（アドレスは設定の認証URLフィールドに指定されています）。
パートナーのOAuth2サーバーが利用できず、エラーを返します。
エクソーラログインが「依存サービスが利用できない」エラー（010-035）を受け取り、処理を続行しません。

トークン交換失敗（エラー 010-015）

ユーザーが認証ウィジェットの Log in with [Your Platform] ボタンをクリックします。
ユーザーはログインまたは同意ページにリダイレクトされます（アドレスは設定の認証URLフィールドに指定されています）。
ユーザーが認証情報を入力し、システムでアクセスを承認します。
システムが認証コードを持ってユーザーをエクソーラにリダイレクトします。
エクソーラがコードをアクセストークンと交換するためにシステムに連絡します（アドレスは設定のトークンURLフィールドに指定されています）。
パートナーのOAuth2サーバーがトークンの発行に失敗し、エラーを返します。
エクソーラログインが「OAuth 2.0アクセストークンの取得中にエラーが発生しました」エラー（010-015）を受け取り、処理を続行しません。

ユーザーデータ取得失敗（エラー 010-036）

ユーザーが認証ウィジェットの Log in with [Your Platform] ボタンをクリックします。
ユーザーはログインまたは同意ページにリダイレクトされます（アドレスは設定の認証URLフィールドに指定されています）。
ユーザーが認証情報を入力し、システムでアクセスを承認します。
システムが認証コードを持ってユーザーをエクソーラにリダイレクトします。
エクソーラがコードをアクセストークンと交換するためにシステムに連絡します（アドレスは設定のトークンURLフィールドに指定されています）。
エクソーラがアクセストークンを使用してシステムからユーザーのプロファイルデータ（ID、メールなど）を取得します（アドレスは設定のYour info URLフィールドに指定されています）。
パートナーのOAuth2サーバーがユーザーデータの返却に失敗します。
エクソーラログインが「ソーシャルプロファイルの取得に失敗しました」エラー（010-036）を受け取り、処理を続行しません。

取得方法

OAuth 2.0を介した認証を有効にするには：

自身のOAuth 2.0プロバイダーの設定で、https://login.xsolla.com/api/social/oauth2/callbackを許可されたリダイレクトURIとして追加し、認証の失敗を防ぎます。
パブリッシャーアカウントでプロジェクトを開き、Players > Loginセクションに移動します。
クラシックログインオプションのパネルでConfigureをクリックします。
Authenticationブロックに移動し、OAuth 2.0 login connectionを選択します。
次のフィールドに入力します：
- Authorization name — 統合名。パブリッシャーアカウントでの識別に使用されます。数字、ラテン文字、ハイフン、アンダースコアを含むことができ、スペースなしで最大100文字です。
- Authorization URL — ユーザー認証に使用されるメソッドのURL。
- Token URL — アクセストークンを取得するために使用されるメソッドのURL。
- Your info URL — アクセストークンを使用してユーザーのプロファイルデータ（IDやメールなど）を取得するために使用されるメソッドのURL。
- Client ID — 認証サーバー上のクライアントの一意の識別子。数字、ラテン文字、ハイフン、アンダースコアを含むことができ、スペースなしで最大255文字です。
- Client secret key — 認証システムによって生成された一意のID。数字、ラテン文字、ハイフン、アンダースコアを含むことができ、長さは8-255です。
- Permission scope — 認証中にシステムがユーザーから要求するアクセス権のリスト（例：openid、profile、email）。
Key name mapを設定します：
- システム内のメールアドレスのキー名を提供します（オプション）。
- システム内のユーザー識別子のキー名を提供します。
Settingsセクションで、追加の認証設定を指定します（オプション）：
- auth_content_type — Content-Typeヘッダーの値。
- auth_header — ユーザーデータを要求する際に認可トークンを渡すヘッダー（ヘッダーでの認証）。
- auth_param — ユーザーデータを要求する際に認可トークンを渡すクエリパラメータの名前（パラメータでの認証）。
- token_type — トークンタイプ。可能な値：Bearer、OAuth。
- use_pkce — 認証中にPKCE（Proof Key for Code Exchange）技術を使用することを示すフラグ。最高のセキュリティ基準を確保するためにこれを有効にすることを強くお勧めします。
注意
キー名は$.で始める必要があります。例：$.response[0].emailおよび$.response[0].id。
認証ウィジェットを介した統合を使用する場合、カスタマイズを設定します：
- Authorization button nameを指定します。最大長は30文字です。
- ロゴをアップロードします。推奨サイズ：24 × 24px。サポートされている形式：JPG、PNG、SVG。
- 認証ボタンの色を設定します。
- Save changesをクリックします。
Login APIメソッドを通じて統合を使用する場合、provider_nameでプロバイダーIDの送信を設定します。形式は"<authorization_name>-<publisher_id>"で、<authorization_name>はプロバイダー設定で指定した統合名、<publisher_id>はパブリッシャーアカウントでのプロジェクトIDです。選択した認証プロトコルに応じて、次のメソッドを使用してprovider_nameパラメータを渡します：

ご意見ありがとうございました！

あなたのメッセージを確認し、体験を向上させるために利用させていただきます。

最終更新日: 2026年7月9日

誤字脱字などのテキストエラーを見つけましたか？テキストを選択し、Ctrl+Enterを押します。

内容

動作の仕組み
認証フロー
初回ログインフロー
リターンユーザーフロー
認証失敗
取得方法