バイトルに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の排他制御 - 問題点 １つのリフレッシュトークンで複数のアクセストークンが発行される

KVSの排他制御 - 対策 RedisのSETNXを使ってLock機能を実装して対応

● 再認証時のAPIリクエストが減った ● マイクロサービス化の第一歩 ● バイトルでログインはこれから OAuth 2.0を導入した結果

● OAuth2.0を導入してアプリの課題を解決できた ● 導入するにあたり、セキュリティは特に注意しないといけない ● マイクロサービス化の第一歩を踏み出せた 今後について ● Webの認証もOAuth 2.0に ● 更にマイクロサービス化を進めていく ● バイトルでログインを含む外部向けのAPIの公開 まとめ

ありがとうございました