認証方式

mimi で選択いただける認証方式について説明します。1つのアプリケーション内で複数のクライアントを扱う場合、デベロッパーはクライアント ID の発行方式を選択することができます。発行方式には、下記の2方式があります。

1. 外部認証サーバーを利用する

デベロッパー側で、mimi の外部にセキュアな認証サーバーを構築しクライアントを認証します。この認証方式を選択した場合は、 mimi Developer API でアプリケーションシークレットを生成、取得します。アプリケーションシークレットは生成時の一度だけ確認することができます。
アプリケーションシークレットは、セキュアな外部認証サーバーに配置することのみ許可されます。
外部認証を通過したクライアントは、外部認証サーバー経由で発行された mimi API アクセストークンを得ることで、mimi の各種サービスを利用できます。 mimi API アクセストークンの発行についての詳細は、認証／認可操作をご参照ください。

外部認証サーバーを利用するケース

エンドユーザーの認証をデベロッパーが独自に行いたい場合です。例えばある家電製品のお客様向け会員サービスを運営している場合、その会員であることが前提となる場合等です。

📘

この場合の利点と注意点

利点

エンドユーザーの認証を独自に行うことができたり、既にある認証サーバーを利用できることです。

注意点

シークレットは、第三者に漏洩しないよう、注意が必要です。エンドユーザーの Web ブラウザ等が解釈するためのスクリプトに埋め込んだりしてはなりません。また、アプリケーションシークレットが漏洩してしまうと、影響範囲がすべてのクライアントに及ぶことになります。そのためセキュリティ上、スマホアプリやデスクトップアプリ等の頒布するネイティブアプリケーションに、アプリケーションシークレットを埋め込んで利用することは禁止とします。

外部認証サーバーを利用する場合のシステム構成図

2. mimi がクライアントを直接認証する

クライアントID とクライアントシークレットのペアを mimi Developer API で新規発行します。クライアントシークレットは作成時に一度だけ確認することができます。mimi が クライアントをクライアントIDとクライアントシークレットによって認証します。この認証を通過するとクライアントに対して mimi API アクセストークンを発行し、mimi の各種サービスを利用することができます。
この認証方式におけるクライアントシークレットは、スマートフォン等のネイティブアプリケーション等に埋め込んで利用することが許可されます。
mimi API アクセストークンの発行については、認証／認可操作をご参照ください。

mimi がクライアントを直接認証するケース

エンドユーザーを独自に認証する必要がない場合や、既存のサービスとユーザー連携する必要がない場合。例えば、使う端末数が少ない場合はセキュリティ管理が容易であるため、外部認証サーバーを使わずに手動でクライアントIDとクライアントシークレットを端末に埋め込んで使用することができます。

📘

この場合の利点と注意点

利点

認証サーバーを別途準備する必要がなく、即座に mimi が利用可能です。

注意点

シークレットは、第三者に漏洩しないよう、注意が必要です。エンドユーザーの Web ブラウザ等が解釈するためのスクリプトに埋め込んだりしてはなりません。

mimiがクライアントを直接認証する場合のシステム構成図