OAuth 2.0の世界観を5分で伝えるために
OAuth 2.0を知らない同僚に、5分で紹介するとしたら何を話せばいいか。
「RFC 6749ではこういった用語やこういった流れが定義されてますよ」という風に説明しても興味を持ってもらえないだろうと筆者は思います。
この記事ではRFC 6749をはじめとする公式の文献にあえて触れずに、口頭でも説明しやすい形でOAuth 2.0のあらすじを紹介していきます。
最初の一言
OAuth 2.0がサポートされているサービスでは、
ユーザー本人から委任状をもらった代理人は、サービス内でユーザーに代わって操作を代行することができる。
という性質が成立します。
言葉が一気にたくさん出てきたのでここから整理していきます。
ユーザーとサービス
ユーザーが何かしらのサービスを利用している、それが大前提になっています。
ユーザーという言葉には、実在する人物の方と、（サービスに入会したことによって）サービスに認知された概念的な存在という二通りの意味が含まれているので、ここでは混同されないように両方とも明示的に表しました。
代理人の登場
普段なら自分でサービスの機能を利用するユーザーですが、自分が直接触っていない間でも機能を使い続けたいという要望があるとします。誰かに頼んで操作の代行をしてもらうためには、その頼まれる誰かがまず存在しなければならない。
ここで代理人という言葉が出てきます。
ここもユーザーと同じように、本体とサービスに認知された存在とに分けています。
委任状の誕生
特定のユーザーが特定の代理人にちゃんと依頼をしたという事実を表すために、その両者を結びつける委任状の存在が必要になってきます。委任状の成立には双方の合意が必要なので、ユーザー側の操作と代理人側の操作という二つのステップに分けられます。
この両者の前後関係から、
- ユーザーが委任状を作成するケース
- 代理人が委任状を作成するケース
が生まれます。
ユーザーが委任状を作成するケース
このケースではまず、ユーザーがサービスに対して、代理人を指名して委任状を作成します。
するとユーザーはサービスから、その委任状を特定できる何らかの情報を入手するので、その情報をサービス外の何かしらの通信手段で代理人に教えます。
代理人がそれを持ってサービスに承認の意を伝えると、ユーザーと代理人の間に有効な委任状が生まれます。
代理人が委任状を作成するケース
このケースではまず、代理人がサービスに対して、自分用の委任状を作成します。
ユーザーと代理人は対等な立場にいなく、ユーザーは事前に（サービス内における）代理人を知ることができるが、代理人は事前に（サービス内における）ユーザーを知ることができないので、上のケースとは展開が異なります。
すると代理人はサービスから、その委任状を特定できる何らかの情報を入手するので、その情報をサービス外の何かしらの通信手段でユーザーに教えます。
ユーザーがサービスに対して、その委任状に自分の名前を書き込むと、ユーザーと代理人の間に有効な委任状が生まれます。
操作の代行
委任状ができると、代理人による操作の代行が可能になります。
サービス側としては、代理人iがユーザーjに代わって操作を行おうとした時に、
- 両者の間に有効な委任状が存在すれば代行を認める
- 両者の間に有効な委任状が存在しなければ代行を認めない
という挙動を取ることになります。
委任状の破棄
ユーザーは依頼関係をいつでも止めることができるので、自分が持っている委任状（および、そこから辿れる代理人）を随時確認することができ、その中から不要になった委任状を破棄することもできます。
最後に: 公式の文献を読んでください
この記事では厳密性を考慮せずに、筆者独自の表現でOAuth 2.0の雰囲気を伝えてきました。OAuth 2.0の詳細については、公式の文献をご参照ください。
- OAuth 2.0の文献一覧: https://oauth.net/2/
- OAuth 2.1の動向: https://oauth.net/2.1/
Discussion