はじめに

こんにちは！
株式会社リンクアンドモチベーションの宮田です。

エンジニアとして2年目になり、普段はRuby on Railsを用いたバックエンドの保守開発を担当しています。

本日、私事で大変恐縮ですが誕生日を迎えましたので、自分へのプレゼントとして認証について詳しくなろうと思います💪

というのも最近、業務の中でお客様とSSO（シングルサインオン）連携の調整を行う機会が増え、Auth0（オースゼロ） の設定に触れることが多くなってきました。

これまではマニュアルや手順に沿って設定を行っていたのですが、お客様との技術的なやり取りの中で「もう少し踏み込んだ仕組みまで把握しておかないと、適切かつ迅速な対応が難しいな」と感じました。

そこで、アドベントカレンダーの機会を活用して、Auth0を通じた認証の仕組みを自分なりに整理してみることにしました。

今回の記事では、

Auth0が「IdP」なのか「SP」なのかという役割の整理
複数のサービス間でSSOが実現される構造
など、調査を通じて「なるほど、そういうことだったのか」と納得した部分を中心にまとめています。

認証基盤にはさまざまなサービスがありますが、今回はAuth0と、外部IdPとしてOktaを例に挙げて説明していきます。

なお、全体の把握と見た目のわかりやすさを優先するためにフローの図解を簡略化して表現しています。 厳密なシーケンス図とは異なる部分があるかもしれませんが、同じように「中身の構造を整理したい」という方の助けになれば幸いです。

目次

1. はじめに
2. Auth0はIdPなの？SPなの？
3. パターン1：Auth0自身がユーザーを管理する場合（IdP）
4. パターン2：外部IdP（Okta等）と連携する基本フロー
5. 連携のための事前設定：「名刺交換」と「荷物の送り方」
- ① 「名刺交換」（メタデータの設定）
- ② 「荷物の送り方」（Binding）
6. なぜログインし続けられるのか？セッションの階層構造
7. SSOの仕組み：複数サービス間の移動
8. おわりに
参考文献

2. Auth0はIdPなの？SPなの？

最初に？が浮かんだのが、「Auth0はIdP（認証を出す側）なのか、それともSP（サービス側）なのか？」という点です。

結論から言うと、Auth0は設定次第でその両方の役割を演じ分けることができます。

パターン1：Auth0がユーザーを管理する場合（IdPとして振る舞う）

いわゆる「メールアドレスとパスワードでログインする」形式です。この時、Auth0自身がユーザー情報を持ち、認証を行う 「IdP（Identity Provider）」 となります。

パターン2：外部IdP（Okta等）と連携する場合（SP・仲介役として振る舞う）

顧客が既に使っているIdP(OktaやAzure AD)などを利用してログインする場合、Auth0は：

アプリに対しては： 「IdP」 のように振る舞い、トークンを発行する。
外部IdPに対しては： 「SP（Service Provider）」 として振る舞い、認証を外に任せる。

つまり、Auth0が間に入ってプロトコルの違いを吸収してくれる 「認証のブローカー（仲介役）」 になってくれるようです。

2. パターン1：Auth0自身がユーザーを管理する場合（IdP）

まずは、Auth0のデータベースにユーザーを保存し、Auth0が直接認証を行う基本的なフローを見ていきます。

① ログインの開始

ユーザーがサービス（アプリ）を利用しようとアクセスします。未ログインの場合、アプリはAuth0へと誘導します。

② 認証情報の入力

Auth0のログイン画面が表示されます。メールアドレスとパスワードを入力し、Auth0が自身のDBで本人確認を行います。

③ 認証成功とセッションの確立

認証が成功すると、ここがポイントですが、2つの重要なものが発行されます。

JWT（アクセストークン等）: アプリが「この人はログイン済みだ」と認識するための鍵。
Auth0 Session: Auth0というサーバー自体がブラウザを覚えておくためのパスポート（Cookie）。

Auth0による認証方法を完全に理解した（この記事のセッションとJWTの説明がわかりやすかったです）

これで、ユーザーは無事にサービスを利用できるようになります。

④ 2回目からのログインが楽な理由

あと、調べていくうちに、JWTはセキュリティのために有効期限がかなり短く設定されるのが一般的であるということがわかりました。

が、そこでふと
「そんなにすぐ期限が切れるなら、なぜユーザーは頻繁にログインを求められないのだろう？」
と疑問が湧きました。

その答えを探っていくとAuth0セッションという仕組みに辿り着きました。

一度ログインした後、アプリのJWT（チケット）が切れてしまったとします。

しかし、ブラウザに「Auth0 Session（パスポート）」が残っていれば、パスワード入力をスキップして新しいJWTを再発行できます。

これが、私たちが普段体験している「一度ログインすれば、しばらくはログイン画面を見なくて済む」という仕組みの正体です。

3. パターン2：外部IdP（Okta等）と連携する基本フロー

次に、本題である「外部のIdP（Oktaなど）を使ってログインする」パターンを見ていきます。Auth0が「仲介役」となるケースです。

① 外部IdPへのリダイレクト

ユーザーがログインしようとすると、Auth0はドメイン設定などを見て「このユーザーはOktaで認証が必要だ」と判断し、Oktaの画面へリダイレクトします。

② Oktaでの認証と検証

Okta側で認証が成功すると、その結果がAuth0に戻ってきます。Auth0は事前に交換しておいた証明書を使って、「本当にOktaから来た正しいデータか？」を厳密にチェックします。!

③ 3層の「鍵」が揃う

検証が通ると、Auth0はアプリ用のJWTを作成します。

最終的に、ブラウザは以下の3つの鍵を同時に持つことになります。これがSSOを理解する鍵です。

JWT: アプリ用のチケット。
Auth0 Session: Auth0でのログイン状態を示すCookie。
Okta Session: 大元の認証基盤でのログイン状態を示すCookie。

4. 連携のための事前設定：「名刺交換」と「荷物の送り方」

このパターン2を実現するためには、Auth0と外部IdPの間で事前の設定が必要です。

① 「名刺交換」（メタデータの設定）

SAML連携は、お互いの「名前」と「住所」を正しく教え合う名刺交換から始まります。

この名刺にあたる情報が「メタデータ」です。

特に重要なのが、以下の2つの項目です。

Entity ID（識別子）:
- いわば「名前」です。「私は urn:auth0:my-tenant という者です」と名乗るための一意のIDです。
ACS URL（Assertion Consumer Service URL）:
- いわば「返信先の住所」です。「認証が終わったら、このURLに結果を届けてください」という窓口になります。

これらをお互いの設定画面に正しくコピペすることで、ようやく「どこの誰に認証を頼めばいいか」「終わったらどこに返せばいいか」が繋がります。

② 「荷物の送り方」（Binding）

設定画面に出てくる「HTTP-Redirect」と「HTTP-POST」は、データの運び方の違いです。「ハガキ」と「小包」でイメージすると分かりやすいです。

	HTTP-Redirect (ハガキ)	HTTP-POST (小包)
使われる方向	行き（Auth0 → IdP）	帰り（IdP → Auth0）
中身	「認証して！」という短い依頼だけ。	ユーザー情報、電子署名、証明書などが詰まった巨大なXMLデータ。
特徴	URLに乗せて送る。軽くて速い。	URLに入り切らないため、ボディに乗せて送る。

基本的には「行き」の依頼はデータが軽いのでRedirect（ハガキ）方式がデフォルトの設定のようですが、システムやセキュリティ要件によっては、行きもHTTP-POST（小包）に指定されることがあります。

Redirect方式だと、ブラウザの履歴やサーバーのアクセスログに「どのURLにアクセスしたか」が残ってしまうので、もしURLの中に機密性の高い情報やトークンが含まれている場合、それがログとして残るのを避けたいという場合もあるようです。

5. なぜログインし続けられるのか？セッションの階層構造

パターン2の最大のメリットは、3層の鍵による長時間ログイン継続できる点です。
アプリのJWT（チケット）が切れても、裏に控える2つのセッション（パスポート）が助けてくれます。

第一弾：Auth0セッションによる復帰

JWTが切れた際、まず 「Auth0 Session」 が確認されます。これが残っていれば、外部IdP（Okta）には問い合わせず、その場ですぐに新しいJWTが再発行されます（サイレント認証というらしい）。

第二弾：Oktaセッションによる復帰

もしAuth0セッションも切れていた場合、Auth0は再度Oktaへユーザーをリダイレクトします。

しかし、ここで大元の 「Okta Session」 が生きていれば、Oktaはパスワード入力画面を出さずに、即座に「認証成功」を返します。

結果として、ユーザーは何も入力することなく、再び全ての鍵が揃った状態に戻ります。

6. SSOの仕組み：複数サービス間の移動

最後に、この仕組みが複数のサービスを跨いだ時にどう機能するかを見ます。これこそがSSOのやりたいことですね。

※かなり簡略化した図にしています。

サービスAからサービスBへの移動

ユーザーはすでに「サービスA」にログインしており、大元の「Oktaセッション」を持っています。この状態で、まだログインしていない「サービスB」を開きます。

Oktaセッションによるログイン

サービスBから認証に飛ばされた瞬間、奥に控えるOktaがブラウザのCookieを確認し、有効な 「Oktaセッション」 を見つけます。

Oktaは「この人はさっきサービスAで本人確認済みだ」と判断し、即座に認証を完了させます。これにより、ユーザーは一切の入力なしでサービスBも使い始めることができます。

7. おわりに

今回、IdPとSPの関係や、セッションの構造を図解しながら整理したことで、自分の中の「ブラックボックス」が大きく解消されました。

この記事が、私と同じように「仕組みがいまいちピンとこない」という方の理解の一助になれば嬉しいです。

参考文献