OAuth/OIDCとSSO関して理解を整理

これは何

認証・認可とは何かという話から、OAuth/OIDC/SSOに関する理解の整理をしました。

正式な定義とは異なる点がある点に注意してください。

省略

• AT
  • アクセストークン

おすすめ書籍

• Auth屋さんの書籍
  • https://www.authya.com/
• パスキーの全て
  • https://gihyo.jp/book/2025/978-4-297-14653-5
• Real World HTTP
  • https://www.oreilly.co.jp/books/9784814400669/

認証(Authentication)

ユーザーが本人であることを確認するプロセスを認証という。

例：サービスの入り口でまずID/PASSでログインするプロセス

様々な認証

• パスワード認証
• ワンタイムパスワード(OTP)
• 生体認証
• パスキー
• OAuth+OIDC

セッション認証

サービスにログイン成功時にセッションIDをブラウザのクッキーに保存する。リクエストごとにセッションIDを送信し認証する。

トークン認証

ログイン後にトークンを発行しクライアントに送信する。クライアントはリクエスト時にAuthorization: Bearer <TOKEN>をリクエストヘッダーにセットすることで認証する。このトークンはAPIへのアクセス権（認可）を表す。

Basic認証

クライアントはリクエスト時にAuthorization: Basic base64(username:password)をリクエストヘッダーにセットすることで認証する。base64は可逆なのでデコードすれば丸見え。

認可(Authorization)

ユーザーの「アクセス権の確認」と「リソースを制限すること」を認可という。

例：Adminユーザーだから〇〇ができる、自身の投稿だから編集できる

• RBAC(Role-Based Access Control)
• スコープベース(OAuth)

OAuthとは

認可のフレームワーク。認証のフレームワークではない点に要注意。

1. 認可サーバーにアクセスし認証プロセスを開始
2. 認可サーバーでユーザー同意を行い許可するスコープを確認（大事）
3. 認可コードを付与してクライアントにリダイレクト
4. クライアントが認可コードを用いてATを取得
5. 発行されたATを利用し、指定されたスコープでリソースサーバーにアクセス

OAuthの良い点

1. AT発行時に認可サーバーにアクセスし認証するため、運営しているサービスで認証情報を預からずに済むためセキュア
2. ATは期限付きである
3. ATにスコープがある

OAuthで出来ること

スコープ付きのATを発行しリソースサーバーから指定のスコープで情報を取得可能にする。

OAuthで出来ないこと

発行されたATで誰かを保証すること（認証には利用できない）

例：GoogleでOAuthのプロセスで指定のスコープでATを発行したとしても、Googleのプロフィール情報の取得などはできるが、そのAT単体で本人確認できない

OIDC（OpenID Connect）

OAuth単体ではできなかった認証が可能になる。

OIDC = OAuth2.0を拡張（IdToken + UserInfoエンドポイント）することで認証機能を追加したもの

例：Googleで認証してポケモンGOにログインする

OIDCのOAuthのプロセスでATとIdTokenが発行される。IdTokenで本人確認ができ、自身のサービス向けに発行されている場合のみATで認可を行うことが可能。※

※ ATでの認可はaudienceが自身のサービスドメインになっている場合のみ利用可能である点に注意。OIDCのデフォルトではUserInfoエンドポイント用でありそのままは利用不可。

OIDCでのOAuthのスコープ

scope=openidはマストで設定する必要がある。これを設定しないとIDトークンが返らずただのOAuthになる。

IdToken

JWT形式でデコードすると中にクレーム（このユーザーはこういう人です）が入っている。JWTのペイロードの中身は以下。

IdTokenは認証結果を含む検証可能な身分証であり、ATと違って認可に利用するものではない。

• iss
  • トークンの発行者. Issuer.
• aud
  • サービス運営者のクライアントID. Audience.
• sub
  • ユーザー識別子.Subject.
• iat
  • 発行日時. Issued At.
• exp
  • 有効期限. Expiration.

JWTに署名がついているため検証することにより改ざんを検知できる。

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

ユーザーがAサービスにログインすれば、Bサービスにもログイン済みになる。一度認証すれば関連サービスもログイン済みとなる仕組み。

SSOは概念でありプロトコルではない。具体的な実現方式はOIDCやSAMLが用いられる。近年はOIDCが主流となっている。

なぜ他サービスでもログイン済みになるのか？

Aサービスにログインした時点でIdPでの認証が完了しIdP側にセッションが保持される。その後、BサービスにアクセスするとOIDCのフローが開始されるが、既にIdP側にセッションが存在するため再度ログインすることなくIdTokenが発行される。

SAML（Security Assertion Markup Language）

OIDCがIdTokenというJWT形式の身分証明書を発行するのに対して、SAMLはXML形式の身分証明書を発行する。

なぜSAMLよりOIDCか

1. XMLのパースは重い
2. OIDCのようにATは発行されないため自前でのAT発行が必要

まとめ

• 認証 = 誰かを確認する
• 認可 = 何ができるかを制御する
• OAuth = 認可の仕組み（アクセストークン）
• OIDC = 認証 + 認可（IDトークン + アクセストークン）
• IDトークン = 本人証明
• アクセストークン = リソースへのアクセス権
• SSO = これらを使った体験（概念）