【SSO】OIDCとSAMLの違い【認証認可】

2021年7月20日 2021年8月9日

こんにちは、yassanです。
OpenIDConnectとSAMLの違いをまとめてみました。

各認証フローについては理解している前提での話になります。ご了承ください。
また、もし間違ってるところがあったら教えてください。

どちらが良い悪いとかはないと思うので、特徴を捉えて適切な技術選定をしたいですね。

OIDC

OIDCでは、IDトークンとアクセストークンの二つを使います。

IDトークンは、認証されたことを証明するもので、
アクセストークンは、認可されたことを証明するものです。

OIDCのトークンは、JSON形式で記述されます。

JSONでも特に、JWT(JSON Web Token)と言うフォーマットで記述されます。
JSON形式で記述された認証情報を暗号化してTokenとする...と言うのがざっくりとした説明になります。

OIDCでは、ユーザー側でSSOするかどうかの選択ができます。

ユーザー側で認可するサービス単位でSSOの対象として許可するかしないかの選択ができます。

OIDCは、ステートレスな通信を行います。
都度トークンを提示して認証認可済であることを証明します。

（もちろん利用するサービスによってはCookieを発行してステートフルな状態にするかもしれませんが、あくまでOIDCとしてはステートレスです。）

OIDCはJWTのフォーマットで決め打ちされていることもあって、含められる情報に限りがありカスタマイズ性が低いです。
とはいえ、必要十分な情報は含めることはできています。

一言で言えば、コンシューマーやイマドキのアプリが使うイメージ。
枠がきっちり決まっていてそれにそって設定さえすればすぐに使えるため、参入しやすいです。

ユーザーに認可の有無を委ねる点が、コンシューマー向きの利用に刺さります。
また、Cookieに依存した設計を回避できるので、モバイルアプリではOIDCを選択する方が良いかと思います。

SAMLでは、SAMLトークンが使われます。
SAMLトークンは、XMLで記述されます。

XMLで定義できる部分は、Coreと呼ばれProtocolとAssertionが含まれます。
Assertionに認証情報の実態があります。
詳しくは【SSO】SAML認証の技術仕様解説【認証認可】で紹介しています。

SAMLでは、アプリに対してのユーザーが許可するしないの概念はありません。
言うなれば、強制的に許可した状態になります。

SAMLの場合は、SPの認証時に一度トークンを使いますが、以降は都度認証することはありません。
代わりに、Cookieを発行してステートフルな通信をします。

SMALはIdPとSPで事前に鍵交換しているため、セキュリティレベルが高い認証といえます。

また、SAMLトークンのフォーマットは特に決まっていないので、認識さえ共通していればある程度カスタマイズすることができます。

一言で言えば、会社が使うイメージ。
セキュリティレベルの高さと、歴史があり実績がある点がポイントかなと思います。

また、ユーザーにサービスへのSSO連携の有無を委ねないため、あらかじめロールが明確に決まっている会社組織の方が相性が良いかと思います。