【テックブログ】認証方式についてまとめてみた

テックブログ エンジニア

いろんな認証方法があるのでまとめてみた。

※ たくさんあるので随時追加していきます。

Basic認証

Basic認証

HTTPで定義される認証方式。

ユーザ名とパスワードの組みをコロン ":" でつなぎ、Base64でエンコードしたものを、リクエストヘッダのAuthorizationフィールドに記載して、サーバーへ送信することでチェックしている。

初回認証後は毎回の通信時に、ブラウザが自動的に Authorizationフィールドに認証情報を記載しているため、都度入力は不要。

HTTP通信で利用できるため利用シーンが幅広く利用難度が低いが、SSL暗号化されていないサイト利用時に通信傍受されると、簡単にパスワードが漏洩してしまうため、次の Digest認証 が生まれた。

Digest認証

Digest認証（見た目はBasic認証と変わらない）

Basic認証におけるパスワード漏洩リスクを改善した認証方法。

サーバー側から発行される nonce や realm といったデータを含めて、ユーザ情報やパスワードをMD5でハッシュ化したものを送信している。これにより、通信傍受されたとしても複号化が困難となり、Basic認証に比べて安全性が担保されている。

サーバーが発行するデータ

  • nonce: ランダムな文字列
  • realm: 認証領域
  • qop: auth または auth-init がはいり、どちらかによりMD5ハッシュ化の範囲が異なる

クライアントが発行するデータ

  • cnonce: ランダムな文字列（多分 clinent + nonce という意味だと思う）
  • nc: nonce-count（同じnonceで、同じnonce-countがリクエストされると異常とみなすための安全装置みたい）

Basic認証同様、リクエストヘッダのAuthorizationフィールドによって認証が行われる。特に response 要素に、下記のロジックで暗号化された認証情報が含められる。

A1 = ユーザ名 ":" realm ":" パスワード
A2 = HTTPのメソッド ":" コンテンツのURI
response = MD5( MD5(A1) ":" nonce ":" nc ":" cnonce ":" qop ":" MD5(A2) )

※ qopがauth-initの場合、A2は次のようになる
A2 = HTTPのメソッド ":" コンテンツのURI ":" エンティティボディ

FIDO認証（Fast IDentity Online Alliance）

顔認証（iPhone）

指紋認証や顔認証といったものに代表される、パスワードの入力を必要としない認証方式のこと。

例えば、iPhoneの顔認証を例にとってみると、

あるサービスに登録する場合、自分のiPhoneと利用サービスのアカウントに対して一意の、新しい公開鍵/秘密鍵のペアを生成し、秘密鍵はiPhoneに保存され、公開鍵は利用サービスに送信され、自身のアカウント情報に紐づけて保存される。

ログイン時には、まずサービスからiPhoneへ認証要求（チャレンジ）がレスポンスされ、それをiPhoneに保存されている秘密鍵で暗号化したものを送り返し、サービス側の公開鍵で検証して認証を行っている。

（個人的に、サービスのアカウントごとに秘密鍵を作っている感覚がなかったので、新しい気付きを得ました）

OAuth認証（Open Authorization）

Twitter認可

SSO（シングルサインオン）を実現するための認証方法の1つ。

アクセストークンを利用した「認可」を実現している。（「認証」と「認可」は別物。）

通常、OAuthは認可を実現する仕組みなので、認証（ログイン）には利用されない...のだが、認可によりサービスがプロフィール情報にアクセスして本人情報を取得することにより、認証のような動作を実現することができる。

OAuthによるソーシャルログインを提供している企業（IdP: Identity Provider）

  • Twitter: OAuth2.0ベースの独自仕様
  • Facebook: OAuth2.0ベースの独自仕様

例えば、Twitterによる認可を例にとってみると、

利用サービスはユーザー経由でTwitterからの認可コードを取得し、それをもってアクセストークンの発行を依頼する。

認可コードが正しい場合、アクセストークンが発行され、利用サービスはそれをアカウントに紐づけて保存する。

アクセストークンを利用することで、利用サービスはユーザーに代わってTwitterへのアクセスが可能となり、ユーザーのプロフィールやツイート情報を取得することができる。

OAuthの流れ

ただしOAuth認証には、アクセストークンが盗まれると悪意のある第三者による不正ログインができてしまう脆弱性が存在する。

この脆弱性をさらに改善したものが、OIDC認証になる。

OIDC認証（OpenID Connect）

SSO（シングルサインオン）を実現するための認証方法の1つ。OAuthを拡張した進化版みたいな感じ。

IDトークン（JWT形式）を利用した「認証・認可」のどちらも実現している。

OIDCによるソーシャルログインを提供している企業（IdP: Identity Provider）

（後日、更新します）

SAML認証（Security Assertion Markup Language）

SSO（シングルサインオン）を実現するための認証方法の1つ。

SAMLとOAuthという2大プロトコルが存在し、それぞれ認証方式が存在しているという状態。

と、ここまで書いてはみたけど、実際に実装してみないとイマイチわからないです...

最後に

Threadsの登録者数の伸びを見ていると、やっぱりSNS認証は強いなと感じます。

認証機能を提供するサービス（IDaaS）の現状のスタンダードは Auth0 だと思われます。

月並みですが、Auth0 といった IDaaSを利用して、OIDC認証やFIDO認証をサクッと組み込める

そんなことができれば、一般的なエンジニアとしては十分なんじゃないでしょうか。