Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
バイトルにOAuth 2.0を導入
Search
Shoei Watanabe
November 26, 2018
0
1.4k
バイトルにOAuth 2.0を導入
Shoei Watanabe
November 26, 2018
Tweet
Share
More Decks by Shoei Watanabe
See All by Shoei Watanabe
SNKRDUNKでGo+gRPCで すすめるモジュラモノリス
sh0e1
4
3.4k
About blockchain full managed node service backend built with Azure
sh0e1
1
410
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Music & Morning Musume
bryan
46
6.2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
Thoughts on Productivity
jonyablonski
67
4.4k
Embracing the Ebb and Flow
colly
84
4.5k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.5k
Navigating Team Friction
lara
183
15k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Statistics for Hackers
jakevdp
796
220k
Speed Design
sergeychernyshev
25
670
We Have a Design System, Now What?
morganepeng
51
7.3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
28
900
Transcript
バイトルにOAuth 2.0を導入 2018/11/26 dip × istyle 合同勉強会
アウトライン 1. 自己紹介 2. アプリが抱えていた課題 3. 何故OAuth 2.0? 4. OAuth
2.0とは 5. システム構成 6. 導入時に注意したこと / 導入後の不具合 7. OAuth 2.0を導入した結果 8. まとめ
渡邊 翔永(Shoei Watanabe) @sh0e12uatanal3e @sh0e1 @sh0e1 ▪ 経歴 • SIer
• フリーランス • ディップ - 2018/06 ▪ スキル • Golang / PHP / JavaScript • GCP • Blockchain ▪ 業務 • サーバサイド • アプリ用API • OAuth 2.0サーバ • 外部のB向けAPI 自己紹介
• 一定期間アプリを起動しないとログア ウト状態になる • 認証トークンの有効期限がいつ切れ るかアプリ側では判定できない • 認証トークンが有効化どうかがAPIへ リクエストを投げてから判断している アプリが抱えていた課題
抱えていた課題の解決 • アクセストークンの有効期限あり ▶ アプリ側で認証のハンドリングが可能 • RFCで仕様が決められている ▶ 独自認証より安全 今後に向けて
• マイクロサービス化 • バイトルでログイン機能の展開 何故OAuth 2.0?
• サードパーティーアプリケーションによるHTTPサービスへの限定的なアク セスを可能にする認可フレームワーク • RFC6749 - https://openid-foundation-japan.github.io/rfc6749.ja.html • Facebook /
Twitter / Googleアカウントでログイン • アクセストークンを使ってリソースを取得 • リフレッシュトークンでアクセストークンを更新 OAuth 2.0とは
• 認可コード • インプリシット • リソースオーナーパスワードクレデンシャル • クライアントクレデンシャル OAuth 2.0の認可グラント
認可コード
インプリシット
リソースオーナーパスワードクレデンシャル
クライアントクレデンシャル
システム構成 - 導入後
フレームワーク • なし、標準のhttpパッケージ OAuth Server • github.com/openshift/osin Storage • 自作パッケージ
▶ 今後OSSで公開していきたい GoのLibrary
• リソースオーナーパスワードクレデンシャル • アクセストークンの有効期限は1時間 • リフレッシュトークンの有効期限は半年 • アクセストークンはJSON Web Token
• スコープはなし バイトルでのOAuth 2.0の仕様
• 総当たり攻撃対策 • パスワード変更はトークンを全削除 • KVSの排他制御 導入時に注意したこと
総当たり攻撃対策 一定期間内に一定回数パスワードを間違える ▼ 強制パスワードリセット
アクセストークン / リフレッシュトークンが漏洩 ▼ パスワード変更 ▼ トークンが有効なままだと、リソースにアクセス可能 パスワード変更時のトークン全削除
KVSの排他制御 - 問題点 1つのリフレッシュトークンで複数のアクセストークンが発行される
KVSの排他制御 - 対策 RedisのSETNXを使ってLock機能を実装して対応
• 再認証時のAPIリクエストが減った • マイクロサービス化の第一歩 • バイトルでログインはこれから OAuth 2.0を導入した結果
• OAuth2.0を導入してアプリの課題を解決できた • 導入するにあたり、セキュリティは特に注意しないといけない • マイクロサービス化の第一歩を踏み出せた 今後について • Webの認証もOAuth 2.0に
• 更にマイクロサービス化を進めていく • バイトルでログインを含む外部向けのAPIの公開 まとめ
ありがとうございました