認証は、システムやネットワークにアクセスしようとするユーザが「正しい利用者かどうか」を確認するプロセスです。
パソコンやスマホの電源を入れた場合にIDやパスワードを入力したり、顔や指紋認証などがあります。
認証の種類
| 名称 | 説明 |
|---|---|
| 知識認証 | 本人しか知らない情報を使うことでパスワードなどがあります。 |
| 生体認証 | 代表的なものに指紋、顔、虹彩（目）があります。 それ以外に筆跡、まばたきなどの行動パターンも生体認証です。 |
| 所有情報 | スマートフォンなどがあります。 SMSにメッセージが送られそれに書かれているコードで認証するのも所有情報を使った認証です。 |
本人認証技術
パスワード認証
パスワード認証はIDとパスワードを使って認証をすることです。
パスワードが他に人にバレてしまうと悪用されてしまう可能性があるため、最近ではパスワード認証だけのサービスは減ってきています。
スマホ認証(FIDO)
スマホ認証(FIDO)(ファイド)はパスワードを使用せず、スマートフォンの本人確認情報を利用するものです。
FIDOが最初に事前準備として、秘密鍵と公開鍵のセットを生成し、認証サーバへ公開鍵とユーザIDを登録します。
認証時にはスマートフォンからWEBサービスなどのサービス提供サーバへ認証要求(①)し、認証サーバへ渡されます。(②)
認証サーバはランダムな値を生成してサービス提供サーバ経由でスマートフォンまで返します。(③④)
スマートフォンで生体認証してスマートフォン利用者が本人であることが確認できたら、これに秘密鍵でディジタル著名して認証サーバへ返します。⑤
認証サーバは公開鍵でディジタル著名を確認して認証完了となります。⑦
シングルサインオン(SSO)
シングルサインオン（SSO）とは、一度のログインで複数のWebサービスやアプリケーションに対しログインできる仕組みです。
例えば、あなたが Google アカウントで Gmail、YouTube、Googleドライブ を使っているとします。
1回Googleアカウントにログインしたら、Gmailも、YouTubeも、Googleドライブも、もう一回ログインしなくて済みます。
社内システムですと、パソコンにログインしたWindowsのアカウント(ActiveDirectoryのアカウント)で、社内のシステムへログインすることで、社内のシステムログインのためのIDやパスワードの入力を省略できます。
これがシングルサインオン（SSO）の考え方です。
シングルサインオン（SSO）にはいくつかやり方(技術)があります。
次の章からはそのやり方を説明します。
SAML
SAML(サムル)は、SSOに用いる通信プロトコルの一つで、異なるインターネットドメイン間でユーザーの認証、認可に関する情報交換をするための仕様です。
1回の認証で複数のサービスにログインできるようになるので、朝一にパソコンへ社内のAzure AD(Microsoftが提供するクラウド型の認証・ディレクトリサービス)でログインすれば、企業が利用している、Gmail（Google Workspace）やZoomなどのサービスをログインせずに利用できます。
SAMLはWEBサーバなどのサービスプロバイダ(SP)と、アイデンティティプロバイダー（IdP）から構成され、情報はXML形式のデータであることが特徴です。
SAMLは下のようにサービスプロバイダ(SP)と、アイデンティティプロバイダー（IdP）から構成されています。
クライアントがWEBサービスなどのSPへアクセス(①)すると、IdPへリダイレクト(②)されるので、クライアントはIDとパスワードを入力(③)します。
IdPがIDとパスワードで認証し、成功するとアサーションが生成します。(④)
生成したアサーションはクライアントへ送られ(⑤)、クライアントは受け取ったアサーションでSPへログインしてSPを利用できるようになります。(⑥、⑦)
なお、すでにIdPにログイン済み（セッションあり）なら、再認証せずにすぐアサーションが発行されます（シームレスSSO）。
また、SAML情報交換の際に使用するアサーションはXML形式であるという特徴があります。
ケルベロス認証
ケルベロス認証は、Windows、Linux、macOSなど、OSの種類にかかわらず利用できる認証技術です。
ケルベロス認証はActive Directoryで推奨される認証方式のため、Windowsを中心とした社内システムのSSOで利用されています。
ケルベロス認証は認証時にチケットを使用することでアカウント（ユーザ ID、パスワード）の漏洩を防いでいます。
ユーザがユーザIDとパスワードをAS（Authentication Server）に送信(①)して、認証に成功するとTGSからTGT（チケット）が発行されます。(③)
チケットの有効期限内であればこのチケットを使って社内のサーバへの認証に使用しています。(④、⑤)
Kerberos を実装するにあたり、ActiveDirectoryサーバにユーザ、グループ、コンピュータなどのプリンシパルを保管が必要です。
ActiveDirectoryであればActiveDirectoryサーバに一元管理されていますが、この情報にあくせすするためにはLDAPというプロトコルが使用されています。
LDAPについて
LDAPとは、ネットワーク機器やユーザーID、パスワードを管理する「ディレクトリサービス」の維持やアクセスを行うプロトコルのことです。
| 名称 | 説明 |
|---|---|
| dc | ドメイン構成要素(下の例だとabc.co.jp) |
| ou | 組織(グループ) |
| cn | 一般名 |
| dn | 識別名(下の一番右のsuzukiの場合、dn: cn=Suzuki , ou=Group1 , dc=jp , dc=co , dc=jp のように表現する。) |
上の絵には描かれていませんが、パスワードもLDAPサーバー上で管理されます。
LDAPは認証の際にパスワードが暗号化されないため、ケルベロス認証などと組み合わせて使用します。
OAuth
OAuthは認可を行うためのプロトコルであり，認可サーバが，利用者 (リソースオーナー)の許可を得て，サービス (クライアント) に対し，適切な権限を付与するためのものです。
OAuthはSNSなどのアカウントで他のサービスへログインできる仕組みです。
「Googleでサインインしますか?」などのメッセージが表示されたことがある場合、OAuthが使われています。
OAuthは、新しいアカウントを作成することなく、さまざまなアプリやサービスにシームレスに接続するためのアクセス許可を付与できます。
OAuthでは、ユーザをリソースオーナー、すでに登録済みのサービス(連携元)リソースサーバ、連携先のサービスをクライアントと表現します。
OAuthは登場人物を次のように表現しています。
- リソースオーナー：ユーザ
- クライアント：Webサービスなどを提供するアプリケーション
- 認可サーバ：認証をする
- リソースサーバ：リソースオーナーのデータを保持
＜OAuthの流れ＞
リソースオーナーがクライアントへログイン要求①すると、認可サーバへリダイレクトして許可要求を出します。②
認可サーバは許可確認画面を表示し、このクライアントへアクセストークンを発行してよいのか確認をします。③
リソースオーナーが許可をすると認可ーサバはアクセストークンを発行します。⑤
コメント