認証と認可について良質な記事を見つけたので内容まとめてみる

5月 15, 20212月 12, 2022

どもです。去年行った夏服断捨離のダメージを受けているsaisaiです。

本日の記事はZennと呼ばれる技術共有記事作成サービスにて非常に良質な記事を読ませていただいたので学んだことをまとめるという非常に他力本願な内容です。

認証と認可について非常に分かりやすまとめていただいている上に無料ですので下記のリンクからぜひ先に読んでみてください！

記事はこちら：認証と認可

今回の記事はあくまで上記記事の個人的見解に基づくまとめであるという点をあらかじめご承知おきください。
また、Active Directory・多要素認証・製品、ソフトウェア、クラウドサービスの章は今回は省略しております。

Contents

1. そもそも認証と認可の違いとはなんだ？
2. OAuthについて
3. OpenID Connectについて
4. SAML2.0とは
5. OpenID ConnectとSAMLの違い
6. Single Sign-Onについて
7. さいごに

そもそも認証と認可の違いとはなんだ？

認証と認可の違いはざっくり以下のように考えます。

認証(Authentication)

・誰であるかを認識する
・エラーコードは401

認証(Authorization)

・権利があるかを確認する
・実質認証の先に認可があることが多い
・エラーコードは403

認証によりユーザーを認識し、そのユーザーに特定の実行権限があるかを認証で確認すると言った流れが多いようですね。

なおも混乱してしまいそうなので記事の受け売りですが"免許「証」を見せれば許「可」する"というフレーズで僕は覚えています(笑)

OAuthについて

OAuthについては本当に知識がなかったのでありがたいです…。

OAuthとは簡単に言えば部分的にサービスへのアクセスを許可する認証方法です。ID/PWによる認証方法ではサービスへの全権アクセスを認可してしまうのでこのような方式が生み出されたようです。

OAuthの認証フローには4つはおおよそ以下の通りです。

①リソース オーナー(ユーザ)が認可サーバにクライアントを登録する
②認可サーバはクレデンシャルを発行する
③クライアント(サードパーティアプリ)にクレデンシャルを登録しておく
④ユーザが認可サーバへ認証を行う
⑤認可サーバはユーザへ認可コードを発行する
⑥リダイレクトで認可コードをクライアントに伝える
⑦クライアントは認可サーバにアクセストークンを要求する
⑧認可サーバはクライアントにアクセススコープを含むトークンを渡す
⑨クライアントはトークンを利用してリソースサーバ(接続したいサービスが稼働するサーバ)へ接続する

上記のフローによってクライアントにリソースで使用するID/PWを登録する必要がなくなります。

ちなみにこのようなフローを認可グラントといいます。

さらに認証の必要なエンドポイントについてもまとめておきます。

・認可エンドポイント
認可サーバのURI、リソースオーナーがブラウザから呼ぶ、認可コードを発行する
・トークンエンドポイント
認可サーバのURI、クライアントが呼ぶ、アクセストークンを発行する
・リダイレクトポイント
クライアントのURI、リソースオーナーが認可サーバのリダイレクトによって自動的に呼ぶ

PKCE(ピクシー)についても確認したましょう。これはOAuth上でのリダイレクトエンドポイントなりすましを防ぐものです。

方法としてはクライアントからブラウザを起動する段階でランダム文字列を渡しておき、その値を認可リクエストにそのまま含むようにします。認可レスポンスのリダイレクトで起動したクライアントは、トークンリクエストに同じ値を添えなければ認可サーバにリジェクトされるようにするというものです。

OpenID Connectについて

OpenID ConnectではOAuthに比べさらに多くの操作ができます。

例えば認証時に、認証日時やより詳細なユーザの情報(名前やメールアドレスなど)を取得できます。

OAuthとの違いはアクセストークンに加えてIDトークンも取得できる点です。

IDトークンとはkey-value形式の情報です。この情報をclaimと言います。
これによりユーザの情報を共通書式でクライアント間で共有できるようになります。

これにより重複したアクセスを解消する認証「single sign-on」を実現することができます。

取得したアクセストークンを異なるクライアントで共有すればいいのでは？
しかし、OAuthには認証の部分がない。つまり許可のみしかできない...
そこでIDトークンを使用し認証も行うことでSingle sign-onを可能に！

SAML2.0とは

XMLをベースとした認証書式、プロトコルです。

SAML2.0では2つのプロバイダーを使用します。

・IdP　認証状況を提供
・SP  認証情報を利用

認証フローとしては以下の通りです。

SP Initiated
①SPにて認証が行われSAML認証要求とともにIdPにリダイレクト
②IdPで認証を行い署名したSAMLアサーションを発行
③SPはSAMLアサーションを受け取り内容をチェック
④SP側にてユーザにサインオンを許可する
IdP-Initiated 
①IdPで認証を行い署名したSAMLアサーションを発行しSPに渡す
③SPはSAML アサーションを受け取り内容をチェック
④SP側にてユーザにサインオンを許可する

SAMLアサーションにはユーザーの認証情報、属性、ユーザーの権限の認可が記載されてます。

OpenID ConnectとSAMLの違い

ざっくり以下のように捉えました。

	OpenID Connect	SAML
クライアント関連系の同意	○	×
ベース	JSON	XML
用途	SNS連携(モダン)	官公庁システムなど(レガシー)
機能数	まだ機能が少ない	多機能
カスタマイズ性	シンプル	複雑
OAuthとの関連性	ある(拡張したもの)	ない

Single Sign-Onについて

認証方法のパターンが複数あったので軽く要約してみます。詳しく知りたい方は元記事を参照ください。

・証明書認証

クライアント証明書を利用します。楽な上セキュアだがクライアント全てに証明書が必要な為導入が面倒…。

・エージェント

クライアントサーバにエージェントを導入します。これも導入が大変そう…。

・代理認証、リバースプロキシ

エージェントの代わりにプロキシサーバあるいはリバースプロキシを立てます。導入の手間が少なく済みますが単一障害点となる可能性があります。

・SAML

SAML対応サービスが対象です。ドメイン単位の信頼関係なのでユーザ確認が不要です。IdP管理者が他ドメインをSPに登録することで信頼範囲を広げることが可能です。

・OpenID Connect

OpenID Connect対応サービスが対象です。クライアント連携時ユーザ確認が必要です。ユーザが権限委譲を許可するほど信頼関係が広がります。

・ケルベロス認証

Windows ログオンや Linux ログインと組み合わせた Single Sign-On が可能になります。