【認証技術.006】利用者認証②

　佐藤@IT雑貨屋です。

　今から二十年近く前には、この利用者認証という技術はそれほど多岐に渡る物はなく、ユーザーID/パスワードによる認証が主流でした。しかもWebブラウザではそれを平文で通信する方法が大半で、いまほどセンシティブな時代ではありませんでした。
　しかし昨今、サイバー攻撃が常態化し、様々なセキュリティインシデントが発生している状況となっていますので、この利用者認証についても「水際技術」として進化しています。

　前回に引き続き、利用者認証の事について書かせて頂きます。

◆WebAuthn
　WebAuth（Web Authentication API）は、Webサイトでの認証を、公開鍵暗号方式を用いて強力にする方式です。FIDO2で使用される認証技術の一つでもあります。
　あらかじめWebAuthnに対応したスマートフォンなどの認証機器でキーペアを生成し、Webサーバに公開鍵を含めた認証情報を登録しておきます。Webサイトへのアクセス時に、認証器で確認を行うことで、正当性を検証することができます。

◆シングルサインオン
　シングルサインオン（Single Sigh-On：SSO）とは、一度の認証で複数のサーバやアプリケーションを利用できる仕組みです。このシングルサインオンの手法には以下のものがあります。

①エージェント型（チケット型）
　SSOを実現するサーバそれぞれに、エージェントと呼ばれるソフトをインストールします。ユーザは、まず認証サーバで認証を受け、許可されるとその証明にチケットを受け取ります。各サーバのエージェントは、チケットを確認することで認証済みであることを判断します。チケットには一般に、HTTPでのクッキー（Cookie）が用いられます。チケットを用いる代表的な認証方式にKerberos認証があります。

②リバースプロキシ型
　ユーザからの要求を一旦、リバースプロキシサーバがすべて受けて、中継を行う仕組みです。認証もリバースプロキシサーバで一元的に行い、サクセス制御を実施します。

➂アイデンティティ連携型
　IDやパスワードを発行する事業者（IdP：Identity Provider）を利用して、一度の認証で様々なリソースを利用する手法です。フェデレーション型とも言われ、企業でのシングルサインオンだけではなく、クラウドサービスでの認証などで一般的に広がっています。

◆アイデンティティ連携
　アイデンティティ連携（ID連携）とは、複数のサービスの間で、認証結果を含む属性の情報を交換、利用することです。属性（Attribute）とは、ユーザのメールアドレスや所属など、サービスを利用するために必要な情報のことです。ユーザの識別するための情報を識別し（Identifier）といいます。
　アイデンティティ連携では、IdPと、IDを受け入れる事業者（RP：Replying Party）の二つが役割を分担します。
　アイデンティティ連携を行う方法の例には、以下のものがあります。

〇SAML
　SAML（Security Assertion Markup Language）は、インターネット上で異なるWebサイト側での認証を実現するために、標準化団体OASISが考案したフレームワークです。現在のバージョンはSAML2.0となっています。
　IDやパスワードなどの認証情報を安全に交換するための仕様で、認証情報のやりとりにXML（eXtensible Markup Language）を用います。通信プロトコルには、HTTPやSOAPが用いられます。SSOを複数サイト間で実現するために利用されます。
　SAMLでは認証情報を提供するIdP（Identity Provider）と呼び、認証情報を利用する側（ID連携でのRPの役割）をSP（Service Provider）と呼びます。WebブラウザからIdPでの認証を経由して、利用者ごと、SPごとの認可を行います。

〇OAuth 2.0
　OAuthとは、権限の認可を行うためのプロトコルです。現在、多くのサービスでは最新バージョンのOAuth 2.0を使用しています。OAuth 2.0では、認可コードやアクセストークンを用いてアクセス権を委譲し、第三者に特定のリソースへのアクセスを認可します。
　OAuth 2.0には、認可コードフローとImplicitフロー、ハイブリッドフローなどのフローがあります。

　・認可コードフロー（Authorization Code Flow(Grant)）
　アクセス主体とは、アクセストークンを使用して、保護されたリソースへのアクセスを行うものです。これは第三者のWebアプリケーションなどが該当します。
　このフローの概要は、アクセス主体の認可の要求をブラウザでリダイレクトし、認可サーバの認可エンドポイントにアクセスします。認可サーバでは認証を行って権限付与を確認し、認可コードを確認します。認可サーバからブラウザ経由でリダイレクトされた認可コードをアクセス主体が取得します。
　アクセス主体は認可サーバのトークンエンドポイントにアクセスし、アクセストークンを取得します。そのアクセストークンを使用して、リソースサーバからサービス提供を受けます。

　・Implicitフロー
　Implicitフローは、認可コードフローを単純化したものです。JavaScriptなどを使用してブラウザ上でアクセス主体が実行される蔵アイアンとに最適化されています。Implicit Grantでは、認可コードを使用せず直接アクセストークンを受け取ります。

　・ハイブリッドフロー
　基本的な流れは認可コードフローと同じです。ハイブリッドフローでは、一つのクライアントに対して二つのトークンを発行することが可能となります。例えば、モバイル端末側のアプリケーションとWebサーバ側のバックエンドアプリケーションからなる構成などで、二つのアクセストークンを用いて両方のアプリケーションが通信できます。

〇OpenID Connect
　OpenID Connect 1.0は、OAuth 2.0プロトコルの上にアイデンティティレイヤを追加したプロトコルです。OAuthは認可プロトコルで、認証については明確な定義がないため、認証部分を追加しています。
　OpenID Connectでは、OpenIDプロバイダは、利用者を認証したあとで、発行者（OpenIDプロバイダ）のデジタル署名付きのIDトークンを発行します。デジタル署名を公開鍵で検証することで、正当な利用者である事を確認できます。

〇PKCE
　PKCE（Proof Key for Code Exchange）は、公開されているスマホアプリなどのクライアントからAuth 2.0認証を安全に行うためのプロトコル拡張です。
　通常のAuth 2.0認証では、リダイレクトのURLを利用して認証コードをクライアントに送ります。この認証コードは、後からアクセストークンに交換するためのものです。しかし攻撃者がリダイレクトのURLを傍受すると、その認証子度を使ってアクセストークンを取得する可能性があります。PKCEは、この問題を解決するために設計されました。

〇本人確認の手法
　本人確認を対面で行う場合には、免許証などと本人の顔を見比べる事で確認できます。しかしオンラインの場合、他人の証明証でなりすまし、他人の画像を利用するなどの方法で本人確認を偽装する事が可能です。そのためにオンラインでの本人確認は、以下の二つを行う必要があります。

　・身元確認
　登録する氏名・住所・生年月日などが正しいことを証明・確認する事です。免許証やマイナンバーカードなどの身分証を利用します。オンラインでの確認よりも、郵送や対面で確認を行う方が、証明レベルは上がります。

　・当人認証
　認証の３要素のいずれかの照合で、当人が作業していることを示す事です。ID／パスワードだけでなく、端末認証や生体認証などを含めることで、認証レベルが上がります。

　オンサインで本人確認を行う場合でも、映像を用いて対面で確認する、その時に送った暗証番号を画面上で手書きで表示させるなどの手法で、信頼性を上げる事が可能となります。