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
Development of authorization system using Authlete and AWS
Search
keita-koga
March 25, 2019
0
1.3k
Development of authorization system using Authlete and AWS
「Authlete Partner Meetup Spring 2019」登壇資料
「AuthleteとAWSで作る認可基盤」
keita-koga
March 25, 2019
Tweet
Share
More Decks by keita-koga
See All by keita-koga
AWSFargateHandsOnStartingWithTerraform
keitakn
0
180
Nuxt.js And TestCode
keitakn
2
4.2k
Featured
See All Featured
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
It's Worth the Effort
3n
180
27k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
1
1.3k
The Language of Interfaces
destraynor
151
23k
Code Reviewing Like a Champion
maltzj
513
39k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
1
3.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
76
41k
GraphQLの誤解/rethinking-graphql
sonatard
50
9.2k
Visualization
eitanlees
135
14k
Code Review Best Practice
trishagee
54
15k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
13
1.5k
How STYLIGHT went responsive
nonsquared
92
4.8k
Transcript
AuthleteとAWSで作る認可基盤 keitakn(古賀圭太)
自己紹介 古賀圭太 フリーランスエンジニア(主にWeb系) Twitter: https://twitter.com/keita_kn_web GitHub: https://github.com/keitakn Qiita: https://qiita.com/keitakn
今日お話すること • Authleteを知ったきっかけ • AuthleteとAWS(API Gateway)を使った認可基盤のシステム構成 • Authleteを選択した理由 • Authleteを導入した結果どうだったか
Authleteを知ったきっかけ(発端) 看護師さんが利用するコミュニティサイトを全面リプレースすることに 運用が始まってから8年以上は経過していました その間一度もリファクタリングされていませんでした
既存システムの調査 さっそくコミュニティシステムのソースコードリーディングを行いました
分かったこと1 コミュニティサイトと聞いていたが実際には様々なドメインを扱うポータルサイトでした • ユーザーが任意のトピックを立てて他ユーザーと交流する機能 ◦ 掲示板サービス • 看護師国家試験の模擬試験を受けられる国家試験対策機能 ◦ 国家試験サービス
• 看護師向けの求人検索が出来る機能 ◦ 求人検索機能 これらの機能が1つのシステムとして密結合な状態で動いていました
分かったこと2 ユーザーの属性によって利用出来る機能に制限があった (例) • 看護学生のみ国家試験サービスを利用出来る • 看護師のみ求人検索サービスを利用出来る • 看護師のみ見れる掲示板、看護学生だけが見れる掲示板があった
アーキテクチャを考えた • インフラをオンプレミスからクラウド(AWS)に移行 • 各アプリケーションを役割毎に分離(フロントバックエンドも分離) • データベースの再構築(必要なデータは移行)
ざっくりシステム構成
APIを保護しなければ • 未認証ユーザーは利用出来るAPIを制限 ◦ e.g. ログイン不要で利用出来る APIのみにアクセス出来る • 各サービスから別のサービスのAPIは呼び出せないように制限 ◦
e.g. 国家試験のフロントエンドから求人検索 APIを呼び出せないようにする • あるユーザーが別のユーザーの個人情報にアクセス出来ないように制限 ◦ セキュリティ的に絶対やってはいけない • ユーザー属性に合わせて閲覧出来る情報を制御 この時点でOAuthが必要だと考えました
OAuthの自前実装はキツイ • 実装を間違えるとセキュリティホールになる • RFCを読み解いて実装に落とし込むのは困難 • 時間的に厳しい 私は過去に社内向けのOAuth基盤を実装した事があります ゆえにその大変さを理解していました
Cognito User Poolsを使えないか? 結論 今回の要件には合わなかった 理由 • ユーザーIDの形式がCognito独自の物になってしまう ◦ マッピングすれば良いがデータコンバートの際にミスするのが怖かった
• ユーザー属性のカスタマイズに限界があった ◦ 住所、電話番号等の一般的な物以外にも独自形式の個人情報がたくさんあった
Authleteを知る きっかけはQiitaの記事でした (参考)Authlete代表 川崎さんのQiita記事 OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
https://qiita.com/TakahikoKawasaki/items/f2a0d25a4f05790b3baa
やりたい事が出来るか実験 結果、問題ないと判断しました これはその時に作ったサンプルコードです https://github.com/keitakn/aws-serverless-prototype (注)3年程前のコードで、まだあまり良く分かっていなかった時期なので、多少実装が雑 なのはご了承下さい
最終的なシステム構成
各サブシステムの説明 • 各サービスのフロントエンド ◦ SSRが可能なフロントエンド( Nuxt.js製) ◦ この単位でAuthleteのクライアントIDを持っている • アカウントサービス
◦ サービスの1つでユーザーのログイン IDやパスワード等を管理 • 認可サービス ◦ 認可エンドポイント、トークンエンドポイントを持っている ◦ この中でAuthleteの認可コードAPIやトークン発行APIを利用 • API Gateway(Amazon API Gateway) • CustomAuthorizer ◦ アクセストークン付きのリクエスト以外は受け付けないように制御 ◦ この中でAuthleteのintrospection APIを利用
トークン発行の流れ
APIコール
Authleteを選定した理由 • 認証と認可を疎結合に作る事が出来るから ◦ 認可に特化したAPI群の提供により、独自の認証システムを使える ◦ ユーザー情報をRDB以外のCognito User Pools等に移すのはキツかった •
API仕様がOAuthやOpenIDConnectに厳密に準拠している ◦ 新しいメンバーにOpenIDConnectに準拠だよって説明で済むのは助かる • Authlete代表 川崎さんのQiita記事 ◦ OAuth関連の説明が分かりやすく、かつ詳しい ◦ この人が作っているサービスなら問題ないかなと思えた
Authleteを導入した結果どうだったか • 認可サービスの実装が非常に楽になった ◦ Node.js + Express + TypeScriptで比較的小規模なアプリケーションで済んだ •
オレオレ実装の旧認可システムを標準的な物に置き換えられた ◦ オレオレ実装を嫌うエンジニアは多い ◦ ググれば分かる仕組み( OAuth)に置き換わったのは大きい
結論 Authleteを選んで良かったです