💁‍♂️

OAuth,SAML,OpenID Connectについての概要（認証・認可）

2022/11/14に公開

プログラミング

入門

tech

背景

SAMLって聞いたけどそれis何、、、
調べてみるとOAuthとかOpenConnectIDとか出てきた。とほほ

基礎知識

どうやらSAMLとOAuthとかを理解する前に認証・認可について理解する必要があるらしい、、、
調べよう

認証（Authentication)

ここでは相手認証について説明する。　
ある人が他の人に自分が確かに本人であると納得させることを認証という。
システムにおいて、
本人一意のIDと他の誰も知りえないであろうパスワードを入力することによって
システム側でログインしてこようとするユーザーがユーザ自身であることを判断している。その行為を認証と言います。

認証には

知識情報：パスワード認証
生体情報：顔認証
所持情報：SMS認証
があり、それらを組み合わせて認証を行うことを多要素認証という

認可（Authorization)

認可（英: authorization）とは、一般的には情報セキュリティおよびコンピュータセキュリティに関わるリソースへの、とりわけアクセス制御へのアクセス権限を特定する機能である。
Wikipedia/認可

あるシステムにアクセスするときに許可するよ、しないよということが認可である。

簡単にいうと

よくあるメタファーで説明
認証：「お前誰？」
認可：「君の素性はわかった、しかし許可は持っているのか？」
↓図解してみた

余談

HTTPのレスポンスでの違い

401 Unauthorized → 認証失敗　「君誰ですのん」
403 Forbidden → 認可の不足　　「素性はわかっておるが、許可できん」

OAuthとは(OAuth2.0)

OAuth (オーオース[1]) は、権限の認可(authorization)を行うためのオープンスタンダードである。2016年現在の最新の標準は、2012年にRFCとして発行されたOAuth 2.0である(RFC6749、RFC6750)ので、本稿でも以下、OAuth 2.0をベースに解説する。
https://ja.wikipedia.org/wiki/OAuth

どうやら「認可」についての話らしい。ここで認証は関係ないことを意識することが重要
そしてOAuthはあくまでも仕様ということです。プロトコル（約束事）みたいなことですね。

アプリとユーザーが分かれており、アプリがユーザの代わりにデータを見ることができている。（権限の委譲）
クライアントアプリにはユーザに関する情報（ユーザーIDやパスワード）を渡していないことが重要である。
どれくらいの権限を与えるのかを決めることもできる。
例）通販サイトに商品を購入すると、自動的に買ったものをツイートする機能があったときに、通販サイトにツイッターのパスワードを保存しておくのは、非常によろしくない（パスワードを書き換えられる危険がある）
そのため、ツイッターのユーザーから「通販サイトからツイートしてもいいよ〜それ以外の機能は触らせないけどね！」許可を取ることでパスワードなしで通販サイトはツイートすることができる

この仕組み全体をOAuthという（OAuth2.0)
登場人物

クライアント（クライアントアプリ）　今回使いたいアプリケーション
リソースオーナー（ユーザー）　Twitterとかのアカウント保持者
認可サーバー　Twitter自身とかGoogle本体であることが多い許可を出すサーバー
リソースサーバー（　データサーバー）　データが入っているサーバー（ツイートのデータが入ってたりする）

OAuthは認可のことなので、OAuth認証と言っている人がいたらこっそり教えてあげましょう

SAML

SAMLとは、Security Assertion Markup Languageの略で、SSO（シングルサインオン）を実現する仕組みのひとつです。読み方は「サムル」またはそのまま「SAML」。SAMLは、OASISによって策定された異なるインターネットドメイン間でユーザー認証を行うための認証情報の規格です。つまり、SAMLはユーザーの認証情報をやり取りするルール・プロトコルを指しています。ちなみにSAML 2.0は、2005年にリリースされたバージョン2.0のSAMLです。
https://boxil.jp/mag/a2950/

認証のためのプロトコルです。異なるアプリケーションに一つのアカウント情報を持ってログインできるようにする認証の規格。それぞれのアプリケーションからIdPにリダイレクトさせて認証を許可させている。

SSO(シングルサインオン)

一度のユーザ認証処理によって、独立した複数のソフトウェアシステム上のリソースが利用可能になる機能または環境である。シングルサインオンによって、ユーザはシステムごとにユーザIDとパスワードの組を入力する必要がなくなる。

登場人物

Identityプロバイダー(IdP)　IDを管理しているところ　（〜ADとかいうやつもある）
サービスプロバイダー(SP)　今回使いたいアプリケーション
ユーザー

下記のイメージです。なんとなくわかりますね。
ログインしようとしてきた、メールアドレスとかのドメインから今回はこのIdPにリダイレクトするよという風に実装します。

OpenID Connect

OpenID Connectは、OAuth 2.0をベースとする、シンプルなアイデンティティ連携プロトコルです。ここでは日本語訳された仕様を紹介しています。原文ならびにその他の仕様については http://openid.net/connect/ をご参照ください。
https://www.openid.or.jp/document/

OAuthで渡していたアクセストークンがIDトークンになったことで認可の仕組みではなく認証の仕組みになりました。Googleを使ってYouTubeなどのアプリケーションにサインインしたり、Facebookを使ってオンラインショッピングのカートにログインしたりする場合に使用されるのが、この認証オプションです。

登場人物

OpenIdentityプロバイダー(IdP)　IDを管理しているところ
RP(Relaying Party)　今回使いたいアプリケーション
ユーザー

サーバーとアプリが直接やりとりしてるのが、SAMLと違う感じするね。

SAMLとOpenID Connectの違い

認証って言っても二つあったね。何が違うんだろう。難しい。→よくわかってないので、知見者求

SAMLは古い標準なので、シングルページアプリケーション（SPA）やスマートフォンアプリケーションなどの最新のアプリケーションタイプの認証に使用するのは非常に困難です。そのために構築されていないからです。逆に、OIDCはそのようなアプリに最適です。

OIDCは、サイズが小さく、軽量プロセスを必要とするJWTを使用します。一方、SAMLに使用されるXMLドキュメントは、はるかに大きく、比較的、処理が困難です。

OIDCは、デフォルトでユーザの同意をサポートします。SAMLでも同じことを達成できますが、大規模な手動開発が必要です。

SAMLは、はるかに長い期間使用されてきたので、今でも政府機関を含む多くの組織に信頼されています。OIDCは、間違いなく機能は豊富ですが、これから追いつこうとしているところです。

OIDCは、特に、基本的なID機能が求められる消費者中心の環境では、設定がはるかに簡単です。

まとめ

認証と認可の違いは抑えましょう。
OAuth２.0は認可のプロトコル
OpenID ConnectとSAMLは認証のプロトコル

実装はいつの日か、、、