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を選んで良かったです