Development of authorization system using Authlete and AWS

144ba23cf73d85b05c56d2cfa45268cb?s=47 keita-koga
March 25, 2019
930

Development of authorization system using Authlete and AWS

「Authlete Partner Meetup Spring 2019」登壇資料

「AuthleteとAWSで作る認可基盤」

144ba23cf73d85b05c56d2cfa45268cb?s=128

keita-koga

March 25, 2019
Tweet

Transcript

  1. 10.

    APIを保護しなければ • 未認証ユーザーは利用出来るAPIを制限 ◦ e.g. ログイン不要で利用出来る APIのみにアクセス出来る • 各サービスから別のサービスのAPIは呼び出せないように制限 ◦

    e.g. 国家試験のフロントエンドから求人検索 APIを呼び出せないようにする • あるユーザーが別のユーザーの個人情報にアクセス出来ないように制限 ◦ セキュリティ的に絶対やってはいけない • ユーザー属性に合わせて閲覧出来る情報を制御 この時点でOAuthが必要だと考えました
  2. 12.

    Cognito User Poolsを使えないか? 結論 今回の要件には合わなかった 理由 • ユーザーIDの形式がCognito独自の物になってしまう ◦ マッピングすれば良いがデータコンバートの際にミスするのが怖かった

    • ユーザー属性のカスタマイズに限界があった ◦ 住所、電話番号等の一般的な物以外にも独自形式の個人情報がたくさんあった
  3. 16.

    各サブシステムの説明 • 各サービスのフロントエンド ◦ SSRが可能なフロントエンド( Nuxt.js製) ◦ この単位でAuthleteのクライアントIDを持っている • アカウントサービス

    ◦ サービスの1つでユーザーのログイン IDやパスワード等を管理 • 認可サービス ◦ 認可エンドポイント、トークンエンドポイントを持っている ◦ この中でAuthleteの認可コードAPIやトークン発行APIを利用 • API Gateway(Amazon API Gateway) • CustomAuthorizer ◦ アクセストークン付きのリクエスト以外は受け付けないように制御 ◦ この中でAuthleteのintrospection APIを利用
  4. 19.

    Authleteを選定した理由 • 認証と認可を疎結合に作る事が出来るから ◦ 認可に特化したAPI群の提供により、独自の認証システムを使える ◦ ユーザー情報をRDB以外のCognito User Pools等に移すのはキツかった •

    API仕様がOAuthやOpenIDConnectに厳密に準拠している ◦ 新しいメンバーにOpenIDConnectに準拠だよって説明で済むのは助かる • Authlete代表 川崎さんのQiita記事 ◦ OAuth関連の説明が分かりやすく、かつ詳しい ◦ この人が作っているサービスなら問題ないかなと思えた
  5. 20.

    Authleteを導入した結果どうだったか • 認可サービスの実装が非常に楽になった ◦ Node.js + Express + TypeScriptで比較的小規模なアプリケーションで済んだ •

    オレオレ実装の旧認可システムを標準的な物に置き換えられた ◦ オレオレ実装を嫌うエンジニアは多い ◦ ググれば分かる仕組み( OAuth)に置き換わったのは大きい