目次 なぜ、OAuth 2.0は「認可のプロトコル」と言われるのか? OIDCは「認証のプロトコル」である OIDCの動作確認 まとめ 本ブログ記事では、Okta Workforce Identity とSaaSアプリ間のフェデレーションで利用できるOpenID Connect (以降、OIDC) について触れてみたいと思います。 認証に関わっていると、「OAuth 2.0は認可のプロトコルだから、認証に使っちゃダメ!認証にはOIDCを使いなさい!」という話を聞くことが多いと思います。 「OAuth 2.0だって認証するじゃん。なんで認可だけなの?」っていう疑問を持って悶々としたままの日々を過ごしていませんか? 「正直、OAuth 2.0とOIDCってどう違うのか、よく分からない。。。」なんて悩みも。 本ブログ記事では、そんな疑問/お悩みを解消できるよう、「こんな感じで説明すれば、分かりやすいんじゃないだろうか?」という思いで、解説をしてみたいと思います。 以降の解説は、以下のブログ記事の内容を実施済み (理解済み) の前提で進めていきます。 ・はじめてのOkta Workforce Identity Cloud (WIC) トライアル環境の構築 ・はじめてのOkta Workforce Identity Cloud (WIC) [第1回] ユーザーと認証器の関係を紐解く ・はじめてのOkta Workforce Identity Cloud (WIC) [第2回] 多要素認証を紐解く ・はじめてのOkta Workforce Identity Cloud (WIC) [第6回] APIってどうやって使うの? (トークン編) ・はじめてのOkta Workforce Identity Cloud (WIC) [第7回] APIってどうやって使うの? (OAuth 2.0認可コード編) ・はじめてのOkta Workforce Identity Cloud (WIC) [第8回] APIってどうやって使うの? (OAuth 2.0 Client Credentials編) なぜ、OAuth 2.0は「認可のプロトコル」と言われるのか? 「OAuth 2.0は認証のプロトコルじゃない。認可のプロトコルだ。」と言われます。 でも、[第7回] のOAuth 2.0 認可コードグラントでは、リソースオーナーは認証していますよね。 なのに、なぜ「OAuth 2.0は認可のプロトコル」だと言われるのでしょうか? この混乱の原因は、主役がちゃんと説明されていないことにあるような気がします。 「認証」だの「認可」だのといっているその主役は、「リソースオーナー」ではなく「クライアント」なのです。 以降、その意味を紐解いていきましょう。 OAuth 2.0の4つの役割 以下は、今回のOAuth 2.0の解説に登場する4役です。 A. 「リソースオーナー」は、リソースの所有者 =「人 (+Webブラウザ) 」です。zsaku.zkawa@atko.emailです。 B. 「クライアント」は、「インターネット上のWebアプリケーション」です。今回の主役です。https://goodweb.shopです。 C. 「認可サーバ」は、「認証と認可を行ってアクセストークンを発行するサーバ」です。https://auth.siteです。 D. 「リソースサーバ」は、リソースオーナーが所有するリソースを預かる場所です。今回の例では「写真やファイルを保存するサーバ」です。https://storager.xyzです。 認可サーバを運営する会社とは異なる会社がリソースサーバを運営している、というイメージです。(これは、OAuthでは一般的な形態です。) クライアントは、OAuth 2.0ではリソースオーナーの認証ができない 「主役はクライアント (goodweb.shop) だ」という観点で、なぜOAuth 2.0では認証が成立しないのか、その理由を、認可コードグラントの例を使って解説します。 [第7回] でご紹介したOAuth 2.0の認可コードグラントを簡単におさらいしますと、下図の (1)〜(8) の流れで、クライアントにアクセストークンが払い出され、クライアントはそのアクセストークンを使って、リソースサーバからリソースオーナーの情報 (リソース) を取得する (下図 (9) と (10) ) というものでした。 「認証」とは、「クライアント (goodweb.shop) が、リソースオーナーが誰なのかを知ること」と考えて、上記の図を眺めてみてください。 (a) クライアント (goodweb.shop) は、(1)〜(7) の中ではリソースオーナーが誰なのかを知ることができるステップがありません。 上図の (2) と (3) で認証が行われていますが、これは「リソースオーナー」と「認可サーバ」との間で認証しているのであって、クライアント (goodweb.shop) は関与していません。 でも、クライアント (goodweb.shop) は、上図の (8) で認可サーバからアクセストークンを受け取っていますので、「じゃぁ、このアクセストークンの中にユーザー名があれば、認証になるんじゃないの?」と思いませんか? その着眼点は正しいのですが、ここがポイントで、「OAuth 2.0の仕様が、そうなっていない」のです。 (b).