はじめに
最近、Vue.js と Flask で API とそれを叩くページを作成しています。
その際、認証周りをどうしようかと悩んで、調べていくと OAuth が
いいんじゃないか、という結論に行きつきますが Qiita などを見ながら調べてもよくわかりませんでした。
そんな中、とってもわかりやすい資料を見つけました。
[Slide Share] 基礎からの OAuth 2.0 - Developers.IO 2017
しかも何と、YouTube で解説動画もあります。
[YouTube] DevelopersIO 2017 基礎からの OAuth 2.0 perform by 都元ダイスケ #cmdevio2017
この資料の内容を部分的にピックアップしていきます。
認証と認可
認証 (Authentication)
通信相手が誰か、確認すること
- ネットワークやサーバへアクセスする際に、本人性をチェックし、正規の利用者であるかどうかを確認。
- 確認方法は通常、ID/Password で行う。
- HTTP status "401 Unauthorized" に関わる
認可 (Authorization)
リクエストが許可されるかどうかを決めること
- 認証によって利用者を識別し、その利用者に合ったアクセス権限の制御を行う。(ポリシー)
- HTTP status "403 Forbidden" に関わる
通常、認証 -> 認可 の流れでユーザは与えられた権限内でリソースへのアクセスを行う。
OAuth 2.0 の登場人物
| キーワード | 説明 |
|---|---|
| Resource owner (RO) | ユーザ、Client のリソースへのアクセスを認可する |
| Client | アプリ、RS が抱えるユーザリソースへのアクセスを行う張本人 |
| Authorization server (AS) | RO/RS の仲介役、Client へ RS へのアクセスのキーとなるアクセストークンを発行する |
| Resource server (RS) | ユーザリソース、アクセストークンがなければアクセスすることができない |
OAuth 2.0 の基本的な流れとしては、RS にあるユーザリソースにアクセスしたい Client が、AS からアクセストークンを発行してもらい、そのアクセストークンを持って Client は RS にアクセスをする。アクセストークンの発行は、 RO が認可をする。
Client がアクセストークンを取得するフロー
Client credentials grant
ポイント
- Client ID + secret => アクセストークン
- リソースオーナーの認可無しに、AS はアクセストークンを発行
- リソースオーナーがフローに介在しないため、Client は好きなスコープでリソースにアクセスできてしまう
Resource owner password credentials grant
ポイント
- User ID + Password => アクセストークン
- Client が リソースオーナーのパスワードを知ってしまう
- 公式 Client 向け
Implicit grant
ポイント
- アクセストークンがユーザやブラウザに見えてしまう
- エンドユーザ支配下にある Client 向け
Authorization code grant
ポイント
- Authorization code (AC) => アクセストークン
- AC はアクセストークンを得るための引換券であり、ユーザやブラウザから見えても問題ない
- サーバサイド Web アプリケーション Client 向け
取得したアクセストークンの送信方法
Authorization ヘッダの Bearer スキームを使用
Authorization: Bearer <ACCESS TOKEN>
おまけ
OAuth の各種フローのシーケンス図は、PlantUML というツールを使用して作成しています。
コードベースで図を作成でき、とてもかんたんです。
ソースコードは、GitHub で公開しておきます。
[GitHub] guromityan/oauth_plant_uml