このビデオは、2020 年 1 月 31 日に開催した弊社勉強会のプレゼンテーション録画のパート 1 です。 OAuth 2.0 と OpenID Connect の概要、JWT (JSON Web Token)、そしてこれらの仕様が策定された当時の状況について、 Authlete の工藤達雄がお話しします。
工藤: 今日の勉強会をやるにあたって案内を書いたんですけれども、 基本的に昔ながらの OAuth, OpenID Connect ではなくて、最近のアップデートを中心に、 とくに我々が注目している部分について、 独断と偏見というところがポイントというか伏線なんですけれども、 お話をしていきたいと思っています。
わたしの紹介はいいですかね。 一昨年から Authlete でやっています。 全体の流れとしては、これまでと、いま注目っていうことと、 あと今後、まだちょっとゆるいんだけれど注目ですってところを、 3 本立てでお話ししていきたいと思ってます。 ということで、2010年代前半の、OAuth 2.0 とOpenID Connect について、 話を進めたいと思います。
まず OAuth 2.0 のあたりは、もう今日はちょっといいかなと思いつつ、一応入れてきました。 OAuth 2.0 とは、アクセス権、つまりアクセスのデリゲーションのフレームワークであり、 かつそれをトークンというものを使って行なうというところがポイントです。
フレームワークであって、RFC 6749 にこのトークン付与プロセスの全体的な流れと、基本的な付与のフローというのが定義されています。 基本的なことしか決まっていなくて、逆にいうとかなり柔軟なところがあって、いろんな使いかたが、仕様が出てから考えられています。 トークンの付与方式とか、トークン自体は何も決まってなかったりとか。 あと、何が、どういう人が関与するかというところも基本的には自由、まあ自由というとアレなんですけど、かなり柔軟性が高いというところですね。
認可サーバーというところがキモになるんですけど、これはRFC 6749から持ってきた図です。 キモっていうのは本当にここだけなんですよね、このCとDで。この前で何をやるか、あとこのトークンを渡した後に何をさせるかが、周辺仕様としていろいろ出てきています。
それから認可グラントに関して、いろんな定義が自由にできます。 それでたとえば認可コードだとか、リフレッシュトークンだとか、クライアントクレデンシャルズって いうのが決まっている、というところがOAuthの仕様です。
OAuthダンスっていうふうによくいいますけど、登場人物の間でいろんなやりとりが行われます。
これは典型的に、認可コードグラントフロー、リダイレクトベースのフローのケースですけれども、この場合にはまず、 …このあたり説明しなくても、もしかしてもういいですかね。
認可リクエストが飛んできて、ユーザー認証と同意があって、認可コードがまたブラウザ経由で渡されて、ここからブラウザリダイレクトで得た認可コードを、 サーバートゥサーバーでアクセストークンに引き換えます。そしてもらったアクセストークンを使って API にアクセスする、というような流れです。
これを拡張したのが OpenID Connect です。 基本的な流れとして、OAuth 2.0 認可コードグラントフローをベースにした認可コードフローがあります。 この黄色い部分が OAuth 2.0 から変わっているところなんですけれども、アクセストークンと一緒に ID トークンも渡します。
IDトークンを使って、リライングパーティ、すなわちOAuth でいうところのクライアントは、IDトークンの中身を見て、 いまアクセスしてきているこの人は誰かを特定して、アクセスさせるかさせないかとか、コンテンツどういうのを返すかとかを決める。
あと必要であればユーザー属性を、あとから UserInfo エンドポイントを叩いて取得する、 そしてそのときにさっきもらったアクセストークンを使う、 という流れになっています。
トークンの形式について、OAuth では決まってないですけど、OpenID Connect のほうの ID トークンは決まっていて、 それを実現しているのがJSON Web Tokenというものです。
ジェイダブリュティーとわたしは言っちゃうんですけれども（注: 仕様上は jot と発音する旨の記述がある）、 この中でキーとバリューのペアがあって、この中でどういうキーを使って、どういうバリューを持っていいかが、 OpenID Connect のほうで、ID トークンの仕様として決まっています。 それを、たとえば署名したり、場合によっては JWE で暗号化する、というかたちになっています。
OAuth 2.0 ではよくトークンの表現形式として JWT が使われるんですけど、 OAuth 2.0 では決まってなくて、これが比較的便利だからよく使われがちです。 なのでここ、「用いられることもある」と、ちょっと但し書きをしています。
いま、OAuth 2.0 と、OpenID Connect と、JSON Web Token、3 つ話しましたけれども、 この3つに関しては、けっこう早い段階でできちゃってるんですよね。
これは 2012 年の Cloud Identity Summitというイベントで Brian Campbellという人が話した資料から抜いてきたやつなんですけれども、 このときに、よく見るとほとんど draft-ietf-何たらかんたらという基本的にインターネットドラフトの段階なんですけど、 だいたいこのパーツはそろってるんですよね。
ちょうどこのときは、まだ OAuth V2 がドラフト、たぶんドラフト 28 とかだと思うんですけれども、その段階でここではトークンの付与っていうのが決められていて、 それをどうやって使うかというところ、このときには Bearer Token がドラフトで、同様に MAC ベースでっていうのがあったんですけど、 これはちょっと使われないというか、誰も進めることがなくなった、というところですね。
あと JOSE、（この中で）JWS、JWE っていうのが別途できていて、それを参照する JWT もこのときにあった、と。
あとグラントのしくみとして、SAML のアサーションを使うだとか、JWT を使うのもこの段階でできていて、 それをたばねるためのもう一個メタなフレームワークっていうものがあって。
でこの全体を使って、OpenID Connect を今後やっていきましょうとか、あるいは UMA をやっていきましょう、というのがあったと。
これが 2012 年の段階で。このときはまだけっこういろいろな仕様がドラフトだったんですけれども、2014 年に OpenID Connectが最終版として出て、 2015 年に、JWT やこのあとご紹介する PKCE というのが RFC の Proposed Standard となって、 だいたい標準化の基本的なところは終わったっていう感じです。
もう 5 年経ったんですよね。 これでもう今もこのままなのかっていうところが、今日の勉強会の主旨です。
まあ、ちょっと違ってきているんですよね。2020年のOAuth/OIDCはなにかというところで、いくつかトピックをご紹介します。
