SAML

　SAMLのリリースは2002年と比較的古く、WebサービスのSSO仕様を標準化することを主な目的に登場した。ID／パスワードといった認証情報を提供するWebサーバ「Identity Provider（IdP）」と、各種サービスを提供するWebサーバ「Service Provider（SP）」とが事前に信頼関係を構築。SPを運営する事業者は、自社の認証サーバだけではなく、IdPで認証を済ませたエンドユーザーにもサービスを提供する。

　その仕組みからセキュリティ強度が比較的高いとされるSAMLは企業利用も進んでおり、企業内サービスとWebサービスのSSOを目的に導入されることが多い。米Googleの「Google Apps」、米salesforce.comの「Salesforce CRM」といったWebサービスはSAMLを使ったIDフェデレーションが可能なので、自社のイントラネットとこれらのWebサービスとのSSOが実現できる。

　市販のIDフェデレーション製品のほとんどは、SAMLによるSSOを可能にしている。ノベルの「NetIQ Access Manager」（旧Novell Access Manager）など、オンプレミスのWebサービスのSSOに焦点を当てた「Webアクセスマネジメント（WAM）」製品の標準機能やオプションとして、IDフェデレーション機能を用意する製品もある。

OpenID

　OpenIDでは、SAMLのIdPに当たる認証情報提供サーバ「OpenID Provider（OP）」と、SAMLのSPに当たるサービス提供サーバ「Relying Party（RP）」との間でIDフェデレーションを実現する。SAMLとの違いは、OpenIDを利用した認証機能を提供しているOPであれば、RPはどのOPとでもIDフェデレーションができることだ。SAMLのように、事前にOPとRPとの間で信頼関係を構築しておく必要はない。

　エンドユーザーがRPへのアクセス時に、認証に利用したいOPのドメインを含むURL（これがエンドユーザーのIDとなる）を指定すると、RPはそのOPと認証情報をやりとりしてエンドユーザーのログインを許可する。実際の動きを簡単に示すと以下のようになる。

1. エンドユーザーはRPへのアクセス時に、OPのドメインを含むURL（ID）を指定
2. RPはOPへアクセスして共通鍵を共有し、この時点で信頼関係を成立
3. RPはエンドユーザーのWebブラウザをOPの認証ページへリダイレクト（自動的に移動）
4. OPからの認証要求を受け、エンドユーザーはOPへ認証情報を送信
5. OPは認証結果をRPへ送信すると共に、エンドユーザーのWebブラウザをRPのサービスページへリダイレクト
6. RPはエンドユーザーのログインを許可

　RPが独自の認証システムを持つ必要がなく、サービスそのものの構築に集中できるなど比較的縛りの少ない仕様であることから、コンシューマー向けを中心に多くのWebサービスがOpenIDを採用した。強化版である「OpenID Authentication 2.0」（OpenID 2.0）では、メールアドレスなどのプロファイルの要求やOP・RP間での情報交換に関する仕様が追加。RPへの新規アカウント登録に必要な情報をOPから取得できるなどのメリットが加わった。一方、URLをIDに利用するといった制限もあり、企業内利用はそれほど進んでいない。

OAuth

　ユーザー認証の仕組みではないが、あるWebサービスが他社サービスのリソースへアクセスすることを認可する仕組みがOAuthだ。FacebookやTwitterなど大手Webサービス事業者が採用したこと、APIを通じて他社のサービスやリソースにアクセスできる使用上の柔軟性の高さから、コンシューマー向けWebサービスを中心に普及してきた。ただしOpenIDと同様、企業内利用の例はそれほど多くない。

　OAuthの動作概念は次のようになる。サービスAがサービスBにあるリソースを取り込む場合を考えよう。サービスAはAPIを利用し、認可を得た上でサービスBのリソースのうち必要なものを取得する。例えば、画像加工サービスのエンドユーザーが他の画像保管サービスに保管した画像を取り込みたい場合、画像加工サービスは画像保管サービスの認可を受けた上で、必要な画像を取得する。

　OAuthは2012年にはバージョン2.0となり仕様が簡略化され、Webサービス事業者にとって扱いやすくなってきた。さらに、独自開発のAPIと連係させ、OAuthでユーザー認証まで実現するケースも出てきている。

OpenID Connect

OpenID Connectの情報はOpenIDファウンデーション・ジャパンのWebサイトにまとまっている《クリックで拡大》

　2014年には、OAuth 2.0をベースとしたOpenIDの最新バージョンである「OpenID Connect」の仕様が公開された。OAuthの持つアプリケーション間の認可の仕組みに、OpenIDの認証の要素を加えてIDフェデレーションを可能にしたプロトコルである。GoogleはOAuth 1.0やOpenID 2.0のサポートを2015年4月で終了すると発表し、OAuth 2.0やOpenID Connectへの移行を促している。OpenID Connectの詳細についてはOpenIDファウンデーション・ジャパンのWebサイトで確認できる。

モバイルの認証

　ここからは、もう1つの要素であるモバイルに視点を移す。いつでもどこでも業務ができるスマートデバイスは、生産性向上に大いに役立つ。実際に私もスマートデバイスを業務に生かしており、その便利さにもう手放せないほどだ。こうした生産性向上の効果に目を付けてスマートデバイスを活用する企業が増えつつある中、モバイルセキュリティの必要性が高まっている。

　こうした状況を受け、リモート操作で端末のデータを削除（リモートワイプ）したりアカウントロックをしたりする「モバイルデバイス管理」（MDM）を中心に、モバイルセキュリティ製品は急速に充実している。中でも、民間の調査機関が今後急速に伸びると予想するのが、モバイル端末向けのID管理／アクセス管理市場である。

　スマートデバイスを使い、社内だけでなく社外からも社内システムへアクセス可能にしたいと考える企業も少なくないだろう。その際、確実に従業員からのアクセスであることを保証するための仕組みとして、認証は不可欠となる。具体的には、ID／パスワードと他の認証手段を組み合わせて認証する「多要素認証」の必要性がさらに増していることは間違いない。これは、前回「ID／パスワード認証は本当になくなる？　『パスワード限界論』の真実」で指摘した通りだ。

端末の認証機能の活用も

　スマートデバイスでの認証を考える上で、見逃せないのが端末の認証機能の活用だ。Appleがスマートフォン「iPhone」で導入した指紋認証機能「Touch ID」は、端末そのものの安全性強化という点で優れている。Appleが「iPhone 6」の投入と併せて開始したモバイル決済サービス「Apple Pay」（国内未提供）では、決済システムの認証にTouch IDを利用する。スマートフォンに搭載された装置をなぞるだけで認証が完了し、生体認証で本人を特定する。

　企業が自社のシステムにTouch IDを利用する動きも現れそうだ。iOS 8以降では、Touch IDをサードパーティーアプリケーションから利用できるようになった。既にコンシューマー向けサービスでは利用が始まっており、例えばLINEは決済サービス「LINE Pay」でTouch IDを使った認証を可能にしている。