Zenn
🏮

"OAuth2.0"についての備忘録

2021/05/29に公開
OAuth 2.0
tech

そろそろ理解したかったので、自分用にまとめました
参考にさせていただいた動画

認可コードフロー

  1. クライアントアプリケーションからリソースサーバーへのアクセストークンを渡すよう認可サーバー内の認可エンドポイントに要求される
  2. 認可エンドポイントがリソースサーバーにあるデータのー所有者（ユーザー情報など）に許可を問い合わせる
    例：クライアントアプリケーションにgoogleアカウントでログインするポップアップを出し、ユーザーIDやパスワードを入力してもらう
  3. 所有者から必要情報を入力してもらい、許可が出れば認可サーバー（認可決定エンドポイント）にてユーザー認証などを行う
  4. クライアントアプリケーションに有効期限が10~30分程度の認可コードを作成し、発行
  5. クライアントアプリケーションは認可コードを受け取ると、次は別の窓口であるトークンエンドポイントへ認可コードを持っていく
  6. 認可コードとアクセストークンをトークンエンドポイントにて交換し、クライアントアプリケーションはアクセストークンを受け取る
  7. 受け取ったアクセストークンでクライアントアプリケーションはリソースサーバーのAPIにアクセスすることができる
  8. API通過後、リソースサーバーはアクセスを受け取り、認可サーバー（イントロスペクションエンドポイント）にアクセストークンの情報を問い合わせる
  9. 認可サーバーはアクセストークンの情報を返し
  10. リソースサーバーはアクセストークンの有効性を確認、クライアントアプリケーションにデータを返す

上記手順のうち

  1. 認可リクエスト
  2. 認可レスポンス
  3. トークンリクエスト
  4. トークンレスポンス
    のみ、認可コードフローで定義されている部分である

インプリシットフロー

🚨もう使わないでと言われているフロー

  1. クライアントアプリケーションからリソースサーバーへのアクセストークンを渡すよう認可サーバー内の認可エンドポイントに要求される
  2. 認可エンドポイントがリソースサーバーにあるデータのー所有者（ユーザー情報など）に許可を問い合わせる
    例：クライアントアプリケーションにgoogleアカウントでログインするポップアップを出し、ユーザーIDやパスワードを入力してもらう
  3. 所有者から必要情報を入力してもらい、許可が出れば認可サーバー（認可決定エンドポイント）にてユーザー認証などを行う
  4. クライアントアプリケーションにアクセストークンを発行
  5. 受け取ったアクセストークンでクライアントアプリケーションはリソースサーバーのAPIにアクセスすることができる
  6. API通過後、リソースサーバーはアクセスを受け取り、認可サーバー（イントロスペクションエンドポイント）にアクセストークンの情報を問い合わせる
  7. 認可サーバーはアクセストークンの情報を返し
  8. リソースサーバーはアクセストークンの有効性を確認、クライアントアプリケーションにデータを返す

認可コードについてのフローをまるっと飛ばしている

用語集

認証

Authentication
who、"何者"なのかを確認するためのもの

認可

Authorization
what、このユーザーが"何をして"いいのかを決める
👉このユーザーというのを認識するために認証が必要
👉認可を行うにはステップとして認証が必要

リソースサーバー

何らかのデータ(要素)を保存しているサーバー

クライアントアプリケーション

リソースサーバーからデータを受け取りたいサービス、アプリ

API

リソースサーバーにあるクライアントアプリケーションからの問い合わせを受け入れる窓口
問い合わせを受けたらリソースサーバーのデータを返す
👉悪意のあるクライアントアプリケーションからの問い合わせを防ぎたい

アクセストークン

クライアントアプリケーションが信頼されていることを証明できるパスポートみたいなもの
これを持っているクライアントアプリケーションは正常にAPIを通過し、リソースサーバーからデータを返してもらうことができる
👉あらかじめクライアントアプリケーションにアクセストークンを渡す必要がある👉認可サーバーから発行してもらう

認可サーバー

２つのエンドポイントを提供

  1. 認可エンドポイント・・・認可リクエストを受け取り、認可画面（ログインポップアップなど）を返す
  2. トークンエンドポイント・・・認可コードを提示されると、アクセストークンを返す

認可コード

クライアントアプリケーションにアクセストークンを渡してもいいという証明書みたいなもの

OAuth2.0

クライアントアプリケーションから認可サーバーにアクセストークンの発行を要求し、認可サーバーがそれに応答する、この一連の"要求"と"応答"が標準化されたもの
正式名称：RFC 6749 (The OAuth 2.0 Authorization Framework)

認可フロー

アクセストークンの発行手順
OAuth2.0には5つの認可フローが存在する

  1. 認可コードフロー
  2. インプリシットフロー
  3. リソースオーナー・パスワード・クレデンシャルズフロー
  4. クライアント・クレデンシャルズフロー
  5. リフレッシュトークンフロー

クレデンシャル

IDやパスワードをはじめとする、ユーザ等の認証に用いられる情報の総称

GitHubで編集を提案

Discussion