Zenn
😎

SSO・Oauth2.0・OIDC・SAML・JWTなど認証・認可関連のコトバを理解する

2024/07/25に公開
JWT
認証
OAuth 2
OIDC
SSO
tech

はじめに

現代のWebサービスにおいて、セキュアかつ便利なユーザー体験を提供するためには、認証と認可の仕組みが欠かせません。シングルサインオン（SSO）、OAuth2.0、OpenID Connect（OIDC）、SAML、JWTなど、多くの技術・プロトコル・概念が存在します。しかし、初学者にとっては、それぞれのコトバが何を指し示しているのかを理解することが難しく感じられます。　私自身も、それぞれをある程度分かったつもりになりつつも、各コトバがどのように関連しているのかを正確には理解できていませんでした。私の整理も含めて、各概念について深堀っていきます。

対象者

  • これらの認証技術をざっくりとは理解している。
  • 認証・認可の違いを理解している。
  • 正確には把握しきれておらず、何を指し示すことばなのかが曖昧になる。

SSO(Single Sign-On、SSO・シングルサインオン)

SSOとは

仕組みのことです。仕組みを指し示す概念と言ってもいいかもしれません。
ユーザーが一度の認証で複数のシステムやアプリケーションにアクセスできる仕組み全般のことを指すます。SSOを実現するための技術・プロトコルは様々ですが、一度のログインで複数のサービスを利用できることを実現した仕組みのことを指します。

SSOのメリット

利便性向上
ユーザーは一度のログインで複数のサービスを利用できるため、ログイン情報の管理が簡単になります。
セキュリティの向上
パスワードの使い回しや簡単なパスワードの使用が減少します。また、中央で認証を管理することで、セキュリティポリシーを統一しやすくなります
管理の効率化
管理者はユーザーアカウントを一元管理でき、ユーザーの追加や削除、パスワードのリセットが容易になります。

Oauth2.0・OIDC(OpenID Connect)・SAML(Security Assertion Markup Language)

Oauth2.0・OIDC・SAMLとは

これらは、すべてプロトコルのことです。ここでいうプロトコルとは、コンピュータシステム間の「通信するためのルール」「処理方式を定めたルール」のことです。つまり、認証・認可の通信ルールが、各プロトコルにて定められた方式があるということです。各プロトコルについてもう少し詳しく調べていきます。

Oauth2.0

Oauth2.0とは

認可のためのプロトコルです。
2012年に公開された、HTTPベースの認可プロトコルです。RFC6749で仕様が定義されています。
https://datatracker.ietf.org/doc/html/rfc6749

Oauth2.0の仕様

Oauth2.0の登場人物（Role）

まずは、Oauth2.0のプロトコルで登場する役割を整理します。役割、Roleなどと言われますが、登場人物くらいにイメージして良いです。（実際には人物ではなくサーバーだったりしますが。）

  1. ユーザー / resource owner
  2. リソースサーバー / resource server
  3. クライアントアプリケーション / client
  4. 認可サーバー / authorization server

マッチングアプリを利用することを前提として、各役割を整理してみます。
マッチングサービス「マッチ」があり、ユーザーAさんが利用しています。「マッチ」はFacebookを利用した認証方式で登録・ログインすることとします。

  1. ユーザー / resource owner
    マッチングアプリを利用するユーザーAさんのことです。　ユーザーは、名前・プロフィール画像・マッチングした相手・いいねした相手など、様々な情報を持っていますので、resource ownerとも言うことができます。

  2. リソースサーバー / resource server
    保護されたリソースをホストするサーバーです。一般的にはユーザーのリソースはデータベースサーバーに格納されています。そのデータベースサーバーに対して、データ抽出条件を指定してユーザーのデータを取得する役割を担っているのがリソースサーバーです。Oauth2.0プロトコルではアクセストークンを基に、適切な権限でリソースに対するアクセスを管理しています。「マッチ」では、Facebookが管理しているリソースサーバーのことを指します。Facebook内で管理している名前・画像などのリソースをアクセストークンに応じて取得することが出来ます。

  3. クライアントアプリケーション / client
    マッチングサービス「マッチ」のことです。

  4. 認可サーバー / authorization server
    リソースサーバーに対するアクセス権限を認可するためのアクセストークンを発行するサーバーです。基本的には、リソースサーバーを管理しているサービス（Facebook）が管理しているものと考えて問題無さそうです。認可サーバーは、ユーザーに対してリソースへのアクセスの可否を確認（アドレス・password入力など）することで、アクセストークンを発行します。
    「マッチ」では、ログイン時にFacebookの認可サーバーに対してログイン情報を入力することで、Facebookのリソースサーバーに名前・プロフィール画像などを取得可能なアクセストークンを発行するイメージです。

Oauth2.0の様々な認可フロー

Oauth2.0のプロトコルにも幾つかのプロトコルが存在しています。登場する役割の紹介をしましたが、それぞれの確認フローや、検証方法などが異なります。

４つの認可フローについて詳細は記述しません。
非常に有名なqiitaの記事を添付しておきます。
https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f

Oauth2.0とは？（2回目)

認可のためのプロトコルと紹介しましたが、４つの認可フローがあるため、１つの仕様で固定されている訳では無いようです。サービスのシステム状況に応じて柔軟に認可フローを構成できる柔軟性を持っています。

それでは、Oauth2.0とはどういったことを定めたプロトコルなのでしょうか。
下記の特徴があると言えそうです。

  1. アクセストークンの発行:
    クライアントアプリケーションは最終的にアクセストークンを取得し、これを使って保護されたリソースにアクセスします。

  2. ユーザーの同意:
    ユーザー（リソース所有者）が、クライアントアプリケーションに対してリソースへのアクセスを許可する必要があります。この同意は、ユーザーが認可サーバーで認証され、許可を与えるプロセスを通じて行われます。

  3. 認可サーバーとリソースサーバーの分離:
    OAuth 2.0は、認可サーバーとリソースサーバーを分ける設計を採用しています。認可サーバーはアクセストークンの発行を担当し、リソースサーバーはアクセストークンを使用してリソースへのアクセスを管理します。

  4. 標準化されたエンドポイント:
    OAuth 2.0は、トークンエンドポイントや認証エンドポイントなどの標準化されたエンドポイントを定義しています。これにより、異なるサービス間での相互運用性が確保されます。

OIDC(OpenID Connect)

OIDCとは

OpenID Connect は OAuth2.0 を拡張する形で策定された、認証フローのプロトコルです。（OAuth2.0の拡張なので、アクセストークンを渡すことも可能）
https://openid.net/specs/openid-connect-core-1_0.html

OIDCの登場人物

※ OAuth2.0の拡張プロトコルということもあって、登場人物に変化は無いです。ただし、認可サーバーを認証サーバーという名目で定義する場合もあります。

OIDCとOauth2.0の違い

結局のところOauth2.0と何が違うのでしょうか。様々な部分で、拡張されている仕様はあるようです。
ただ、イメージを掴むためにデフォルメした理解でいうと、2点の拡張部分を把握しておくと良いと思います。

  1. IDトークン (ID Token)
    OIDCでは、認証が成功するとIDトークンが発行されます。このIDトークンは、JWT（JSON Web Token）形式で、ユーザーに関する情報（クレーム）を含みます。IDトークンは、ユーザーが認証されたことを証明するために使用されます。
  2. ユーザー情報エンドポイント (UserInfo Endpoint)
    Oauth2.0にはなかったエンドポイントとしてユーザー情報を取得するエンドポイントを用意します。認証が成功した後、クライアントアプリケーションはユーザー情報エンドポイントにリクエストを送信して、追加のユーザー情報を取得できます。これにより、ユーザーのプロフィール情報や属性情報を取得することができます。

SAML(Security Assertion Markup Language)

SAMLとは

認証・認可のプロトコルです。
Oauth2.0・OIDCとは異なった認証・認可フローを辿ります。
IdP(Identity Provider)とSP(Service Provider)の認証フローを介してSSOを実現するプロトコルとなっています。
企業はIdPの認証基盤を利用することで認証を１元管理し、SAML認証を有するSPであるアプリケーション郡とSSOを実現可能です。

IdP(Identity Provider)とは

ユーザーの認証を担当するエンティティです。具体的には、ユーザーがログインする際に、ユーザーの身元を確認し、認証情報を管理します。IdPは、ユーザーの認証に加えて、ユーザー属性情報（名前、メールアドレス、役職など）を保持し、これを他のサービスに提供する役割も果たします。

例えば、下記のサービスがIdPとしての認証基盤を提供しています。

  • Okta
  • OneLogin
  • Microsoft Azure AD
  • Google Workspace
  • Ping Identity
    など。（自前でも可能です。）

SP(Service Provider)とは

ユーザーがアクセスしようとするサービスやアプリケーションを提供するエンティティです。SPは、IdPから提供された認証情報（SAMLアサーション）を受け取り、これに基づいてユーザーを認証し、サービスへのアクセスを許可します。
例えば、下記のサービスがSPとしてSAML認証が可能となっています。

  • Salesforce
  • Google Apps
  • Office 365
  • Dropbox

IdPとSPの認証フロー

実際に、IdPとSPでどういった認証フローを辿るのかは、下記の記事が非常に理解しやすかったのでご参考にしてください。

SP目線から

https://engineers.safie.link/entry/2022/07/29/SAML認証を用いたSSO(シングルサインオン)を実装する#SAML認証について

IdP目線から

https://devblog.thebase.in/entry/2022/10/03/180000

JWT（JSON Web Token）

JWTとは

JWTとはデータ形式のことです。
OIDCなどでトークンをJWT形式のトークンでやりとりすることが一般的かと思います。JWTはある一定のルールをまとったデータ形式のことです。IDトークンとして利用されることが一般的です。

JWTの形式

JWTは下記の形式を持っています。

  • ヘッダー（Header）
  • ペイロード（Payload）
  • 署名（Signature）

JWTの署名方法

JWTの中で、重要で理解が複雑になる部分は署名の箇所かとおもいます。
署名の方式は3種類利用されます。

  1. HMAC（ハッシュベースメッセージ認証コード）
  2. RSA（公開鍵暗号方式）
  3. ECDSA（楕円曲線デジタル署名アルゴリズム）

よく利用される暗号方式は、2. RSA（公開鍵暗号方式）かと思われます。
秘密鍵と公開鍵のペアを利用して、署名と検証をすることでトークンの正当性を評価します。
秘密鍵は認可サーバーのみが持ち、公開鍵は各サービス（リソースサーバーなど）に配布されてトークンの生成時などに利用されます。

公開鍵暗号方式を自作された方の記事は読み応えあり、大変参考になりました。
https://qiita.com/bobunderson/items/d48f89e2b3e6ad9f9c4c

まとめ

いかがでしたでしょうか。少しは各コトバの理解が上がっていると嬉しいです。
概念なのか、プロトコルなのか、データ形式なのか、暗号方式なのか。それぞれのコトバがどういった定義かが分かると詳細に調べていく際にも役に立つかなと思います。
私も整理しながら、深堀っていきました。まだまだ理解不足なところもあるかと思います。不備などがあればご指摘いただけますと幸いです。

Discussion