3rd Party API on Rails - Speaker Deck

3rd Party API on Rails

by tsuwatch

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© ZOZO, Inc. https://wear.jp/  3 ● ファッションコーディネートアプリ  ● 1,600万ダウンロード突破、コーディネート投稿総数は1,300万件以上（2022年6月末時点）  ● ピックアップタグから最新のトレンドをチェック  ● コーディネート着用アイテムを公式サイトで購入可能  ● WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレント・デザイナー・インフルエンサーといった各界著名人も参加 

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© ZOZO, Inc. 5 APIの公開  ● WEARのコーディネートデータを広く活用し、他サービスを通じてファッションの悩みを解決  ○ コーディネート検索APIを提供  ■ Yahoo!天気  ● 現在の天気からおすすめのコーディネート  ■ Yahoo! BEAUTY  ● 髪型に合っているコーディネート  ■ ZOZOTOWN PayPayモール店  ● 販売している服を使用したコーディネート  背景  ※ 実際のYahoo! 天気アプリでの表示

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© ZOZO, Inc. 8 アプリケーションの構成  ● WEAR  ○ API  ■ WEARアプリ用既存API  ○ 3rd Party API  ■ 3rd Party用新規API  ● リソースの取得、スコープの確認  ● AuthZ Service  ○ API  ■ AccessTokenの発行、検証  ■ 公開鍵の提供  ○ Management Web  ■ 開発者用管理画面  ● クライアントIDの発行 

Slide 9

Slide 9 text

© ZOZO, Inc. 9 スコープの設計  ● 仕様  ○ 大文字と小文字を区別しない  ○ スペース区切りのリストで表現  ○ 省略した場合無効とするかデフォルト値とする  ○ https://www.rfc-editor.org/rfc/rfc6749#section-3.3  ● 例  ○ Twiiter  ■ tweet.read  ● TwitterのツイートをGETする系のAPIが使える  とても自由度が高く、どう作るか自分たちで考える必要がある 

Slide 10

Slide 10 text

© ZOZO, Inc. 10 スコープの事例  ● スコープ例  ○ repo  ■ repo:status  ■ repo:invite  ○ write:packages  ○ read:packages  ○ admin:org  ● コロンでネームスペースを区切ってうまく考えている印象  ○ 権限:リソース、リソース指定だけで全権限  ● スコープ指定なしでパブリックな情報へのアクセス権限付与  GitHub OAuth Apps 

Slide 11

Slide 11 text

© ZOZO, Inc. 11 スコープの事例  ● スコープ例  ○ https://www.googleapis.com/auth/youtube.readonly  ■ YouTubeアカウントの表示  ○ https://www.googleapis.com/auth/youtube.upload  ■ YouTube動画のアップロード、管理  ● URLの形式  ○ text/plainでスコープ名がレスポンスされる  ○ パスに権限が表現されている  ○ 内部でこのURLにアクセスして動的になにかしら制御している？  YouTube Data API 

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© ZOZO, Inc. 14 スコープの事例  サービス  スコープ例  GitHub  ● repo  ○ repo:status  ● write:packages  ● admin:org  YouTube  ● https://www.googleapis.com/auth/youtube.readonly  ● https://www.googleapis.com/auth/youtube.upload  LINE  ● profile  ● profile%20openid%20email  Twitter  ● tweet.read  ● users.read  ● follows.write 

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© ZOZO, Inc. 18 WEARで導入しているスコープ  ● Ruby on Railsでエンドポイントごとにスコープを分割するのは簡単にできそう  ○ 細かく分割しすぎるとスコープの管理コストがとても高い  ○ 作成権限を付与して、更新権限がないというのはあまり考えられない  ● 結論  ○ read or write:controller_name  ■ リソース名はcontroller_nameで取得しつつ、権限はもう少し大雑把にする  ■ readとwriteで分割  ● read  ○ GET  ● write  ○ POST、PUT、PATCH、DELETE  結局どうしたのか 

Slide 19

Slide 19 text

© ZOZO, Inc. 19 スコープの検証  def required_read_scope scope_name = "read:#{controller_name}" render_unauthorized unless current_access_token.scopes.include?(scope_name) end def required_write_scope scope_name = "write:#{controller_name}" render_unauthorized unless current_access_token.scopes.include?(scope_name) end 権限ごとにメソッドを実装 

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© ZOZO, Inc. 21 1st Partyでも利用したい  ● ほぼほぼ全APIが利用可能  ○ allというスコープを用意し、read、writeで制御しているスコープについて全権限付与  def required_read_scope return if current_access_token.scopes.include?('all') scope_name = "read:#{controller_name}" render_unauthorized unless current_access_token.scopes.include?(scope_name) end def required_write_scope return if current_access_token.scopes.include?('all') scope_name = "write:#{controller_name}" render_unauthorized unless current_access_token.scopes.include?(scope_name) end

Slide 22

Slide 22 text

© ZOZO, Inc. 22 特定クライアント専用のAPIを提供したい  ● 権限とリソースの組み合わせのスコープ  ■ クライアント間でユニークなスコープではない  ● 意図しないクライアントにも権限が付与されてしまう可能性      ● zozotownなどのクライアント名をスコープとして追加  ○ クライアント単位でユニークなスコープを作成  ■ 特定のクライアントからのみ利用されることを保証 

Slide 23

Slide 23 text

© ZOZO, Inc. 23 特定クライアント専用のAPIを提供したい  ● クライアント名でスコープを作成  ○ allを付与していても利用できなくすることが可能  def required_specified_scope(custom_allow_scope) render_unauthorized unless (custom_allow_scope & current_access_token.scopes).present? end class CoordinatesController < ApplicationController before_action -> { required_specified_scope(‘zozotown’) }, only: [:show] def show; end end

Slide 24

Slide 24 text

© ZOZO, Inc. 24 実際に導入してみて  ● controller_nameが同じになってしまい、意図せず権限を付与してしまうケース  ○ 例：read:coordinates  ■ GET v1/coordinates/:id（CoordinatesController#show）  ● コーディネートの詳細  ■ GET v1/companies/:id/coordinates（Companies::CoordinatesController#index）  ● Companyのコーディネート一覧  ○ 企業のコーディネート情報の権限は付与したくない場合の回避策  ■ 新たな権限を設ける  ● company:coordinates  ■ スコープを意識したパスを考える  ● read:company_coordinates  ■ ネームスペースも含める  ● read:companies::coordinates 

Slide 25

Slide 25 text

© ZOZO, Inc. 25 実際に導入してみて  ● スコープとAPIを同時に設計する必要がある  ○ APIを実装したら半自動的にスコープ名も決定  ■ 誰のためのどういうリソースなのかを考える必要があり、良い設計になりやすい  ● ※APIを実装しようと思ったらすでに同名エンドポイントがあり、既存APIの処理内容に違和感があるということが起こりにくくなりそう  ● スコープ名を見ただけでどのエンドポイントが利用できるか影響範囲がわかりやすい 

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© ZOZO, Inc. 27 今後の課題  ● 各社制限のつけかたは十人十色  ○ 全エンドポイント、エンドポイント単位、特定のグループ単位  ● 一応RFCに仕様があるので従っておいたほうが良さそう  ○ https://datatracker.ietf.org/doc/html/draft-polli-ratelimit-headers-01  ○ レスポンスヘッダ  ■ RateLimit-Limit: 単位時間内の割り当てられているリクエスト数  ■ RateLimit-Remaining: 単位時間内に割り当てられている残りのリクエスト数  ■ RateLimit-Reset: 割り当てがリセットされるまでの時間  ○ リソースサーバでアプリケーションごとに実行回数をDBなどに保存してレスポンスするとか  Rate Limit   