SSO・Oauth2.0・OIDC・SAML・JWTなど認証・認可関連のコトバを正確に理解する
はじめに
現代の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で仕様が定義されています。
Oauth2.0の仕様
Oauth2.0の登場人物(Role)
まずは、Oauth2.0のプロトコルで登場する役割を整理します。役割、Roleなどと言われますが、登場人物くらいにイメージして良いです。(実際には人物ではなくサーバーだったりしますが。)
- ユーザー / resource owner
- リソースサーバー / resource server
- クライアントアプリケーション / client
- 認可サーバー / authorization server
マッチングアプリを利用することを前提として、各役割を整理してみます。
マッチングサービス「マッチ」があり、ユーザーAさんが利用しています。「マッチ」はFacebookを利用した認証方式で登録・ログインすることとします。
-
ユーザー / resource owner
マッチングアプリを利用するユーザーAさんのことです。 ユーザーは、名前・プロフィール画像・マッチングした相手・いいねした相手など、様々な情報を持っていますので、resource ownerとも言うことができます。 -
リソースサーバー / resource server
保護されたリソースをホストするサーバーです。一般的にはユーザーのリソースはデータベースサーバーに格納されています。そのデータベースサーバーに対して、データ抽出条件を指定してユーザーのデータを取得する役割を担っているのがリソースサーバーです。Oauth2.0プロトコルではアクセストークンを基に、適切な権限でリソースに対するアクセスを管理しています。「マッチ」では、Facebookが管理しているリソースサーバーのことを指します。Facebook内で管理している名前・画像などのリソースをアクセストークンに応じて取得することが出来ます。 -
クライアントアプリケーション / client
マッチングサービス「マッチ」のことです。 -
認可サーバー / authorization server
リソースサーバーに対するアクセス権限を認可するためのアクセストークンを発行するサーバーです。基本的には、リソースサーバーを管理しているサービス(Facebook)が管理しているものと考えて問題無さそうです。認可サーバーは、ユーザーに対してリソースへのアクセスの可否を確認(アドレス・password入力など)することで、アクセストークンを発行します。
「マッチ」では、ログイン時にFacebookの認可サーバーに対してログイン情報を入力することで、Facebookのリソースサーバーに名前・プロフィール画像などを取得可能なアクセストークンを発行するイメージです。
Oauth2.0の様々な認可フロー
Oauth2.0のプロトコルにも幾つかのプロトコルが存在しています。登場する役割の紹介をしましたが、それぞれの確認フローや、検証方法などが異なります。
4つの認可フローについて詳細は記述しません。
非常に有名なqiitaの記事を添付しておきます。
Oauth2.0とは?(2回目)
認可のためのプロトコルと紹介しましたが、4つの認可フローがあるため、1つの仕様で固定されている訳では無いようです。サービスのシステム状況に応じて柔軟に認可フローを構成できる柔軟性を持っています。
それでは、Oauth2.0とはどういったことを定めたプロトコルなのでしょうか。
下記の特徴があると言えそうです。
-
アクセストークンの発行:
クライアントアプリケーションは最終的にアクセストークンを取得し、これを使って保護されたリソースにアクセスします。 -
ユーザーの同意:
ユーザー(リソース所有者)が、クライアントアプリケーションに対してリソースへのアクセスを許可する必要があります。この同意は、ユーザーが認可サーバーで認証され、許可を与えるプロセスを通じて行われます。 -
認可サーバーとリソースサーバーの分離:
OAuth 2.0は、認可サーバーとリソースサーバーを分ける設計を採用しています。認可サーバーはアクセストークンの発行を担当し、リソースサーバーはアクセストークンを使用してリソースへのアクセスを管理します。 -
標準化されたエンドポイント:
OAuth 2.0は、トークンエンドポイントや認証エンドポイントなどの標準化されたエンドポイントを定義しています。これにより、異なるサービス間での相互運用性が確保されます。
OIDC(OpenID Connect)
OIDCとは
OpenID Connect は OAuth2.0 を拡張する形で策定された、認証フローのプロトコルです。(OAuth2.0の拡張なので、アクセストークンを渡すことも可能)
OIDCの登場人物
※ OAuth2.0の拡張プロトコルということもあって、登場人物に変化は無いです。ただし、認可サーバーを認証サーバーという名目で定義する場合もあります。
OIDCとOauth2.0の違い
結局のところOauth2.0と何が違うのでしょうか。様々な部分で、拡張されている仕様はあるようです。
ただ、イメージを掴むためにデフォルメした理解でいうと、2点の拡張部分を把握しておくと良いと思います。
- IDトークン (ID Token)
OIDCでは、認証が成功するとIDトークンが発行されます。このIDトークンは、JWT(JSON Web Token)形式で、ユーザーに関する情報(クレーム)を含みます。IDトークンは、ユーザーが認証されたことを証明するために使用されます。 - ユーザー情報エンドポイント (UserInfo Endpoint)
Oauth2.0にはなかったエンドポイントとしてユーザー情報を取得するエンドポイントを用意します。認証が成功した後、クライアントアプリケーションはユーザー情報エンドポイントにリクエストを送信して、追加のユーザー情報を取得できます。これにより、ユーザーのプロフィール情報や属性情報を取得することができます。
SAML(Security Assertion Markup Language)
SAMLとは
認証・認可のプロトコルです。
Oauth2.0・OIDCとは異なった認証・認可フローを辿ります。
IdP(Identity Provider)とSP(Service Provider)の認証フローを介してSSOを実現するプロトコルとなっています。
企業はIdPの認証基盤を利用することで認証を1元管理し、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目線から
IdP目線から
JWT(JSON Web Token)
JWTとは
JWTとはデータ形式のことです。
OIDCなどでトークンをJWT形式のトークンでやりとりすることが一般的かと思います。JWTはある一定のルールをまとったデータ形式のことです。IDトークンとして利用されることが一般的です。
JWTの形式
JWTは下記の形式を持っています。
- ヘッダー(Header)
- ペイロード(Payload)
- 署名(Signature)
JWTの署名方法
JWTの中で、重要で理解が複雑になる部分は署名の箇所かとおもいます。
署名の方式は3種類利用されます。
- HMAC(ハッシュベースメッセージ認証コード)
- RSA(公開鍵暗号方式)
- ECDSA(楕円曲線デジタル署名アルゴリズム)
よく利用される暗号方式は、2. RSA(公開鍵暗号方式)かと思われます。
秘密鍵と公開鍵のペアを利用して、署名と検証をすることでトークンの正当性を評価します。
秘密鍵は認可サーバーのみが持ち、公開鍵は各サービス(リソースサーバーなど)に配布されてトークンの生成時などに利用されます。
公開鍵暗号方式を自作された方の記事は読み応えあり、大変参考になりました。
まとめ
いかがでしたでしょうか。少しは各コトバの理解が上がっていると嬉しいです。
概念なのか、プロトコルなのか、データ形式なのか、暗号方式なのか。それぞれのコトバがどういった定義かが分かると詳細に調べていく際にも役に立つかなと思います。
私も整理しながら、深堀っていきました。まだまだ理解不足なところもあるかと思います。不備などがあればご指摘いただけますと幸いです。
Discussion