STRIXではOAuth 2.0仕様に基づいた認証認可の機能を利用することができます。ゲームサーバーとゲームプログラムが一体となって、OAuthが規定する4種のロールのうちclientとして振る舞い、resource serverがホストするprotected resourceとしてのプレイヤーの識別情報にアクセスします。
STRIXがサポートするOAuth client typeはpublicであり、native application profileに基づいています。また、authorization code grantの利用を想定しています (必要であれば、クライアントプログラムの設計により、client credentials grantなど他のgrantを利用することもできます)。
トークン認証を利用するためにはサーバー側に設定が必要です。Strix Cloudの場合には、アプリケーションダッシュボードの [オプション] 画面で [認証/認可] を有効にします。[ユーザーリソース取得API URL] には、resource serverの、「ユーザーの識別情報を提供するサービス」のエンドポイント (OpenID ConnectのUserInfo endpointのようなもの) のURLを指定します。protected resourceである識別情報の形式は (OpenID Connectのopenidスキーマのような) JSONオブジェクトであることを想定しており、その中には「ユーザーID」("sub" claimのようなもの) と「ユーザー名」("name" claimのようなもの) が含まれていることを前提としています。
実際のOAuthのフローは次のようになります。
- ゲームプログラムはプラットフォームの標準ウェブブラウザーを起動し、authorization serverのauthorization endpointにアクセスしてresource owner (プレイヤー) にauthorization codeを取得させます。
- ゲームプログラムは、このauthorization codeを受け取って、OAuth clientとしてauthorization serverのtoken endpointにアクセスしてaccess tokenを取得します。
- ゲームプログラムはaccess tokenをSDKに渡します。 (Strix Unity SDKの場合はStrixNetwor.instance.authorizationAccessToken に設定します。Strix Unreal SDKの場合はInitializeStrixNetworkWithHttpAccessToken関数の引数に指定します。) するとこのトークンは、サーバーとの接続処理の一環でSTRIXサーバーに転送されます。
- STRIXサーバーは、このトークンを用いてOAuth clientとしてresource serverにアクセスし、(OAuthから見た) protected resourceであるプレイヤーの識別情報を取得します。
以上でOAuthとしてのフローは終了ですが、その後STRIXサーバーはSTRIXとしてのクライアント認証トークンを発行し、それによってそれ以降のクライアント認証を行います。また、そのクライアント (プレイヤー) がルームに参加した際にresource serverから取得した識別情報の一部 (ユーザー名とユーザーID) を自動的にルームメンバープロパティに設定します。