アプリケーション開発者目線で、認証デバイスの実装を考えてみる
こんにちは。
「認証デバイスってどうやって実装するの…」「認証サービスを選択するための判断基準がわからない…」
とお悩みではありませんか？
そんなアプリケーション開発者に向けて、認証デバイスの実装方法を紹介します！
この記事は以下の悩みがある人におすすめ！
本記事を読み終わる頃には、「認証デバイスの実装方法の方針が決まる」ようになりますので、ぜひご覧ください！
1 認証デバイスを実装するためのポイント
アプリケーションに認証デバイスを実装するとき、おさえておきたい以下のポイントがあります。
この2つのポイントを観点に、実装方法を検討します。
そうすると結果的に「開発する（している）アプリケーション」に適した実装方法を選択することができます。
2 認証デバイスの使用目的
アプリケーションで、「何を目的に認証デバイスを使用するのか？」を整理してみましょう。
使用目的の多くは、アプリケーションのログイン時のユーザ認証です。
しかし、アプリケーションはリリースして終わりではなく、機能などのアップデート開発が継続して行われます。
「認証デバイスをログイン以外でも使えない？」
すでにアプリケーションへの実装を成功させている場合、知識と経験からアイデアの実現はそれほど難しくありません。
ただし、認証デバイスの実装方法によっては、実現が難しくアプリケーション開発者を苦しめることがあります。
実装方法に大きく影響されるケースをご紹介します。
「ユーザと認証デバイスが紐づくケース」とは、ログイン認証のように、認証デバイスを持っている人をアプリケーションのユーザとする関係です。
「ユーザと認証デバイスが紐づかないケース」は、認証デバイスを持っていれば、ユーザは特定しません。例えばZipの暗号/復号に認証デバイスを使用するケースです。
実装後に後悔しないために、認証デバイスの使用目的が、「認証デバイスの二次活用の要望が出そうか？」「ユーザに紐付けない使い方をするか？」を考えてみましょう。
3 アプリケーションの構成
次は認証デバイスを使用するアプリケーションの構成について整理してみましょう。
ここでは便宜上、スタンドアローンとクライアントサーバ（WEBシステム含む）に分けます。
認証デバイスを使用するアプリケーションの構成が、どちらになるか確認してください。
4 認証デバイスの実装方法は？
お待たせしました。ここからは認証デバイスの実装方法をご紹介します。
実装方法は以下の3つに分類し説明します。
・組み込み型
認証デバイスメーカーのSDK（Software Development Kit）を使って、認証デバイスの検証処理をアプリケーション内に作り込みます。
既存アプリケーションへの影響は小さく、開発者の自由に実装できるのが特徴です。
また、アプリケーション内で認証デバイスの処理を完結できるため、オフライン環境でも使えます。
SDKによっては、仕組みを理解するための学習コストが発生します。
・サービス型
ユーザと認証デバイスの管理、ユーザ認証処理までをサービス提供します。
複数の認証デバイスに対応しているサービスもあります。
サービスの提供方法は、オンプレミスやクラウドなど様々です。オンプレミスは、クラウドと比べ運用負荷が大きくなることに注意しましょう。
認証デバイスによるユーザ認証をサービス側で処理してくれるため、少ない学習コストで実装できます。その反面、アプリケーションはサービスと通信できる環境が必須条件になります。
既存アプリケーションへの影響は大きく、「ユーザ情報の二重管理」「アプリケーション内のユーザ情報をサービス側に移行（外出し）」など、ユーザ情報をどのように管理するか検討・改修する必要があります。
・DAuth
認証デバイスの検証処理をサービス提供します。複数の認証デバイスに対応しています。
認証デバイスの検証はDAuthで処理し、ユーザ認証の処理はアプリケーション側で従来通り行います。そのため、既存アプリケーションへの影響は小さく、少ない学習コストで開発者の自由に実装できるのが特徴です。
DAuthの提供方法はクラウドです。
開発者はサーバ構築や運用管理に手間をかけることなく利用できます。
アプリケーションは、DAuthと通信するためインターネット環境が必須条件になります。
【組み込み型】
実装イメージ
| アプリケーションの構成 | メリット | デメリット |
|---|---|---|
| 共通 | ・既存アプリケーションへの影響が小さい ・ユーザと認証デバイスが紐付かないケースにも対応できる ・オンライン、オフラインに依存しない | ・学習コストが大きい ・複数の認証デバイスに対応する場合、それぞれの認証処理の作り込み、契約が必要になる |
| スタンドアロン | ・改修が発生するとアプリケーションの再配布や修正パッチなど必要 | |
| クライアントサーバ | ・改修が発生した場合、サーバの改修のみで済む |
【サービス型】
実装イメージ
| アプリケーションの構成 | メリット | デメリット |
|---|---|---|
| 共通 | ・認証処理はサービスから提供されるAPIを呼ぶだけ ・複数の認証方法（デバイス）に対応している ・認証デバイスに関することは、サービス提供側でメンテナンスしてくれる | ・ユーザの二重管理、またはユーザ情報をサービス側に移行するなど、既存の仕組みへの影響が大きい ・ユーザと認証デバイスが紐づかないケースには対応できない ・クラウドサービスの場合、オンライン環境でしか使えない |
| スタンドアロン | ・アプリケーションがインストールされている端末が、サービスまで通信できる環境が必要 | |
| クライアントサーバ | ・サーバのみ、サービスまで通信していれば利用可能 |
【DAuth】
実装イメージ
| アプリケーションの構成 | メリット | デメリット |
|---|---|---|
| 共通 | ・既存の仕組みへの影響が小さい ・ユーザと認証デバイスが紐づかないケースにも対応できる ・認証処理はサービスから提供されるAPIを呼ぶだけ ・複数の認証方式（デバイス）に対応している ・認証デバイスに関することは、サービス提供側でメンテナンスしてくれる ・APIの動作検証サイトがあり、アプリケーションに実装前に動作確認ができる | ・オンライン環境でしか使えない |
| スタンドアロン | ・アプリケーションがインストールされている端末がインターネットに接続できる環境が必要 | |
| クライアントサーバ | ・サーバのみインターネットに接続していれば利用可能 |
5 【パターン別】おすすめの実装方法
ここまで読んでいただいて「どの実装方法が、アプリケーションに向いているかわからない？」という方もいらっしゃると思います。
そこで、アプリケーション開発者の悩みや要望から、おすすめの実装方法を用意しましたので、参考にしてください！
1.ユーザの管理も含め、外部サービスを利用したい
⇨「サービス型」がおすすめです！
アプリケーションのユーザと認証デバイスを外部サービスで管理します。
※既存アプリケーションに認証デバイスを実装する場合は、仕様変更の範囲が大きくなり注意が必要です。
2.既存アプリケーションへの影響を小さく実装したい
⇨「組み込み型」「DAuth」がおすすめです！
既存のユーザ認証処理の手前に、認証デバイスの検証処理を入れることで実装できます。オフライン環境では「組み込み型」、オンライン環境では「DAuth」という選択もできます。
3.認証デバイスを二次活用したい
⇨「組み込み型」「DAuth」がおすすめです！
ユーザに紐付けず認証デバイスを使用する場合、「サービス型」では実現が難しいです。オンライン環境であれば、アプリケーション配布後のメンテナンス面でもすぐれている「DAuth」がおすすめです。
4.複数の認証デバイスに対応したい／WEB・非WEBの利用シーンがある
⇨「サービス型」「DAuth」がおすすめです！
「CUI（キャラクタ・ユーザ・インタフェース）では、OTP（ワンタイムパスワード）が使える認証デバイス」、「WEBアプリケーションではFIDO認証デバイス」と、認証デバイスにも利用シーンによる相性の良し悪しがあります。「組み込み型」では、それぞれの認証デバイスごとの契約や学習コストが発生するため、複数デバイスに対応している「サービス型」「DAuth」がおすすめです。
６ まとめ
この記事では、アプリケーション開発者目線で、認証デバイスを実装するときのポイントを紹介しました。
以下にまとめたので、わからない部分は再確認してくださいね！
認証デバイスは、アプリケーションから独立し単体でも利用できます。
そのため、「認証デバイスを導入した後の二次活用の相談」「別アプリケーションで使用している認証デバイスの対応依頼」のように、自分が作成したアプリケーション以外でも、認証デバイスを利用することがあります。
他アプリケーションに実装するときの手離れの良さも、自分だけではなく関係者にとっても大切なことですね。是非、実装方法を選択するときのポイントに加えてみてください。
いかがでしたか。
認証デバイスの実装方法の方針は見えてきたでしょうか？
より具体的な実装に関するご相談も受け付けています。
こちらからお問い合わせください。
最後まで読んでいただき、ありがとうございました！
このコラムにコメントする
コメントは承認制とさせていただいているため、反映まで少しお時間をいただきます。あらかじめご了承ください。