量子耐性（Post-Quantum Cryptography / Quantum-Resistant）とは、 👉 将来、量子コンピュータが実用化されても破られない暗号・セキュリティ設計のことです。 <h2 id="ha40b6c4569">まず一言で</h2><blockquote>量子耐性＝「量子コンピュータが出てきても、会社のデータ・通信・署名が安全でいられる状態」</blockquote>

量子耐性とは？

<h3 id="h76ce43719f">現在の暗号の前提</h3>今のインターネット・クラウド・SaaSは主に👇に依存しています。<ul><li>パスワード</li><li>SSL/TLS（HTTPS）</li><li>電子署名</li><li>API認証</li><li>クラウドの鍵管理</li></ul>これらの多くは 「古典コンピュータでは解くのに何万年もかかる」 という前提で安全が保たれています。

なぜ今、話題になるのか？

実用的な量子コンピュータが登場すると、<ul><li>今まで 何万年かかる計算 が</li><li>数時間〜数日 で解ける可能性がある</li></ul>👉 つまり 「今は安全な暗号」が、ある日突然すべて無力化される。

量子コンピュータが何を変えるか

<h3 id="h82ac763e41">① 「将来解読」リスク（Harvest Now, Decrypt Later）</h3><ul><li>今の通信やデータを盗んで保存</li><li>量子時代に まとめて解読</li></ul>➡️<ul><li>顧客データ</li><li>契約書</li><li>知財</li><li>認証情報</li></ul>が 数年後に一気に漏洩する可能性。 <h3 id="hd0131d4bcc">② 影響が大きい企業・システム</h3>特に危険なのは👇<ul><li>長期保存が前提のデータ</li><li>認証・署名に依存するSaaS</li><li>金融・医療・インフラ</li><li>グローバル展開企業</li></ul>※ スタートアップ7期目でも 「SaaS / プラットフォーム企業」は将来直撃します。

経営・事業への本当のリスク

<h3 id="h6dba2610e0">技術的には</h3><ul><li>量子でも破れない暗号方式へ移行</li><li>暗号を 後から差し替え可能 な設計にする</li></ul><h3 id="h83e44c7dfb">経営的には</h3><ul><li>「暗号方式を固定しない」IT設計</li><li>将来の規制・顧客要求への 保険</li></ul>

量子耐性とは「何をすること」か？

誤解<ul><li>量子はまだ先</li><li>大企業の話</li><li>CTOの技術課題</li><li>すぐ導入が必要❌</li></ul>実際<ul><li>準備は今から必要</li><li>SaaSほど影響大</li><li>取締役会レベルのリスク管理</li><li>今は「設計と方針」が重要</li></ul>

よくある誤解 ❌

量子耐性とは 「将来、暗号が壊れる前提で会社のITとデータを設計しておくこと」今やらないリスクは “気づいた時には全部作り直し” <h2 id="h848dacb228">現実的アクション</h2><h3 id="h09afd0a4d7">今すぐやること（重くない）</h3><ul><li>暗号・認証を ライブラリ依存にしない</li><li>クラウド／ID基盤を 標準準拠に</li><li>「量子耐性は将来対応」と 方針を明文化</li></ul><h3 id="hde3453f365">今やらなくていいこと</h3><ul><li>高額な量子暗号導入</li><li>専門チーム設置</li></ul>

まとめ

まだまだ実用段階にない量子コンピュータですが、5年～10年後には、実用化されて一般的な存在になるかもしれません。5年～10年というと投資計画の対象になったりするのではないでしょうか。今から考えることが大切だと改めて感じました。量子コンピュータ時代を安全に過ごすためにも、早めの検討、投資計画を！

おわりに

今から考える量子コンピュータ時代

GuardDuty Malware Protection for Amazon S3 の提供が開始しました。<blockquote>指定した S3 バケットに組み込みのマルウェアとウイルス対策を使用できるため、 悪意のあるファイルの評価を大規模に自動化することに伴う運用の複雑さとコストオーバーヘッドを排除できます。</blockquote>こちらを利用することで、今までやっていた、ウイルス対策が比較的簡単になります！また、多くの案件にマッチする条件になっております。<blockquote>リリース時点では、この機能は最大 5 GB のファイルサイズをサポートします。 これには、最大 5 レベルのアーカイブファイルと、解凍後 1 レベルあたり 1,000 ファイルが含まれます。</blockquote>料金はスキャンしたGBと件数で変わるようです。<blockquote>料金は、スキャンされたオブジェクトの GB ボリュームと 1 か月あたりに評価されたオブジェクトの数に基づいています。</blockquote>参考サイト：https://aws.amazon.com/jp/blogs/news/introducing-amazon-guardduty-malware-protection-for-amazon-s3/

Amazon GuardDuty で S3 のマルウェア検知できるようになりました。

結論

参考サイト：https://dev.classmethod.jp/articles/s3-bucket-antivirus-lambda/ 参考サイトにあるようにポリシーを書きまくって、Lambdaをつくってということを設計してました。ウイルス検出に掛かるコストは安く、アプリの規模によってはこちらを採用するのもありかもしれません。その代わり、ウイルス定義の更新やウイルス情報のキャッチアップが必要など運用のコストが高く、おすすめはいたしません。

AWS Lambda で頑張る

あとはサードパーティー製のサービスを利用するケースもあるかと思います。基本的に設定に掛かる手間が省略できるので、こちらもおすすめです。あとは料金との相談ですね！・Antivirus for Amazon S3　参考サイト：https://tech.andpad.co.jp/entry/2024/04/04/100000・Cloud One - File Storage Security　参考サイト：https://qiita.com/chankoba/items/282d8ead7d29a522a282

サードパーティー製サービスを利用する

AWS S3 のウイルスチェック方法（今まで）

AWS S3 のウイルスチェックが変わる！？

まず、<code>Gemfile</code> に以下の行を追加します。<pre><code>gem 'omniauth'
gem 'omniauth-openid-connect'</code></pre> その後、以下のコマンドを実行して gem をインストールします。<pre><code>bash
bundle install</code></pre>

OmniAuth gem のインストール

<code>.env</code> に <code>CLIENT_ID</code> , <code>CLIENT_SECRET</code> を記載します。<pre><code>COGNITO_DOMAIN= 'https://aaaa.com'
CLIENT_ID= 'xxxxx'
CLIENT_SECRET= 'yyyy'</code></pre> <code>COGNITO_DOMAIN</code>: Cognito のドメイン<code>CLIENT_ID</code>: Cognito のクライアント ID<code>CLIENT_SECRET</code>: Cognito のクライアントシークレット

環境変数の設定

次に、<code>config/initializers/omniauth.rb</code> に以下の設定を追加します。<pre><code>Rails.application.config.middleware.use OmniAuth::Builder do
&nbsp; provider :openid_connect, {
&nbsp; &nbsp; name: :cognito,
&nbsp; &nbsp; scope: [:openid, :email, :profile],
&nbsp; &nbsp; response_type: :code,
&nbsp; &nbsp; discovery: true,
&nbsp; &nbsp; client_options: {
&nbsp; &nbsp; &nbsp; port: 443,
&nbsp; &nbsp; &nbsp; scheme: 'https',
&nbsp; &nbsp; &nbsp; host: ENV['COGNITO_DOMAIN'],
&nbsp; &nbsp; &nbsp; identifier: ENV['CLIENT_ID'],
&nbsp; &nbsp; &nbsp; secret: ENV['CLIENT_SECRET'],
&nbsp; &nbsp; &nbsp; redirect_uri: 'http://localhost:3000/auth/cognito/callback'
&nbsp; &nbsp; }
&nbsp; }
end</code></pre> <code>redirect_uri</code>: 認証後のリダイレクト先 (ローカル環境の場合: <code>http://localhost:3000/auth/cognito/callback</code>)

config の設定

<code>app/sesson_controller.rb</code> を設定します。<pre><code>class SessionsController &lt; ApplicationController
&nbsp; def create
 reset_session
&nbsp; &nbsp; auth = request.env['omniauth.auth']
&nbsp; &nbsp; user = User.find_or_create_by(uid: auth.uid, provider: auth.provider) do |u|
&nbsp; &nbsp; &nbsp; u.email = auth.info.email
&nbsp; &nbsp; &nbsp; u.name = auth.info.name
&nbsp; &nbsp; end

&nbsp; &nbsp; session[:user_id] = user.id
&nbsp; &nbsp; redirect_to root_path, notice: 'Signed in!'
&nbsp; end

&nbsp; def destroy
&nbsp; &nbsp; reset_session
&nbsp; &nbsp; redirect_to root_path, notice: 'Signed out!'
&nbsp; end

&nbsp; def failure
&nbsp; &nbsp; redirect_to root_path, alert: 'Authentication failed, please try again.'
&nbsp; end
end</code></pre>

コントローラの設定

ルーティングに OmniAuth のコールバック URL を追加するために、<code>config/routes.rb</code> を編集します。<pre><code>Rails.application.routes.draw do
&nbsp; get '/auth/:provider/callback', to: 'sessions#create'
&nbsp; get '/auth/failure', to: 'sessions#failure'
&nbsp; delete '/logout', to: 'sessions#destroy'

&nbsp; root 'home#index'
end</code></pre>

ルーティングの設定

ユーザー情報を保存するための <code>User</code> モデルを作成します。<pre><code>rails generate model User provider:string uid:string name:string email:string
rails db:migrate</code></pre>

User モデルの設定

ログインボタンやログアウトリンクをビューに追加します。例えば、<code>app/views/home/index.html.erb</code> に以下のように記述します。<pre><code>&lt;% if session[:user_id] %&gt;
&nbsp; &lt;p&gt;Signed in as &lt;%= current_user.name %&gt;&lt;/p&gt;
&nbsp; &lt;%= link_to 'Sign out', logout_path, method: :delete %&gt;
&lt;% else %&gt;
&nbsp; &lt;%= link_to 'Sign in with Cognito', '/auth/cognito' %&gt;
&lt;% end %&gt;</code></pre> <code>current_user</code> ヘルパーを追加するために、<code>app/controllers/application_controller.rb</code> に以下のメソッドを追加します。<pre><code>class ApplicationController &lt; ActionController::Base
&nbsp; helper_method :current_user

&nbsp; def current_user
&nbsp; &nbsp; @current_user ||= User.find(session[:user_id]) if session[:user_id]
&nbsp; end
end</code></pre>

ビューの設定

以上で、SSO認証(openid_connect) の実装が完了します。簡単に認証が実装できていいですね！

最後に

実装

AWS Cognito を使って SSO 認証してみた

<a href="https://github.com/zricethezav/gitleaks" target="_blank" rel="noopener noreferrer">Gitleaks</a>は、機密情報をハードコードすることを防ぐ静的解析ツールです。つまり、クレデンシャルなどの情報がソースコード上にあった場合、「そんな大切な情報載せてええんか！？」って叱ってくれます。例えば、gitleaks detect -vとコマンドを打つと、検出された機密情報が表示されます。 以下は直打ちしたCognitoのClient IDが入っていた場合です。<pre><code> $ gitleaks detect -v

 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

Finding: clientId: 'XXXXXXXXXXXXXXXXXX',
Secret: XXXXXXXXXXXXXXXXXX
RuleID: generic-api-key
Entropy: 4.209867
File: nuxt.config.ts
Line: 12
Commit: e9d73...
Author: daichiccchi
Email: daichi.aoki@example.com
Date: 2024-05-07T06:21:24Z
Fingerprint: e9d73d2236826a222ef27386b9ce7aa2cd6a1821:nuxt.config.ts:generic-api-key:12

8:11AM INF scan completed in 541ms
8:11AM WRN leaks found: 1</code></pre>

そもそもgitleaksって何ぞや

今回はCloud9(Amazon Linux 2)にインストールしていきます。<pre><code># 1.ダウンロード
$ curl -OL https://github.com/zricethezav/gitleaks/releases/download/v8.13.0/gitleaks_8.13.0_linux_x64.tar.gz

# 2.解凍
$ tar -zxvf gitleaks_8.13.0_linux_x64.tar.gz 
LICENSE
README.md
gitleaks
$ ls
gitleaks gitleaks_8.13.0_linux_x64.tar.gz LICENSE README.md

# 3.実行権限付与
$ chmod +x gitleaks

# 4.パスの通っているディレクトリに移動
$ sudo mv gitleaks /usr/local/bin/

# 5.動作確認（バージョンが表示されればOK）
$ gitleaks version
8.13.0

</code></pre>

gitleaksのインストール手順

今回はhuskyというライブラリを使用しました。<pre><code>$ mkdir project-dir
$ cd project-dir
$ git init
$ npm init -y
# huskyをインストール
$ npx husky-init &amp;&amp; npm install</code></pre>ここまでコマンドを実行すると、project-dir直下に<code>.husky/pre-commit</code>ファイルが作成されます。このファイルに記述したコマンドがgit commitの際に実行されます。<code>.husky/pre-commit</code>ファイルを下記のように修正して、コミット時に機密情報を検出するようにします。 （ちなみに<code>--staged</code> オプションで<code>git add</code> 済みのファイルを検出の対象としています。）<pre><code>#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

gitleaks protect --staged // 追記</code></pre> 動作確認試しに機密情報を載せた状態でコミットしてみます。コミット時にgitleaksコマンドが実行されており、「そんな情報載せたコードのコミットなんて許しまへんで」と、しっかり怒られました。コミットもされていません。<pre><code>$ git commit -m 'test'

 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

Finding: clientId: 'XXXXXXXXXXXXXXXXXX',
Secret: XXXXXXXXXXXXXXXXXX
RuleID: generic-api-key
Entropy: 4.209867
File: nuxt.config.ts
Line: 12
Commit: e9d73...
Author: daichiccchi
Email: daichi.aoki@example.com
Date: 2024-05-07T06:21:24Z
Fingerprint: e9d73d2236826a222ef27386b9ce7aa2cd6a1821:nuxt.config.ts:generic-api-key:12

8:11AM INF scan completed in 541ms
8:11AM WRN leaks found: 1
husky - pre-commit hook exited with code 1 (error)</code></pre>

git commit時にハードコーディングがないかをチェックする方法

こちらはGithubActionsを使ってワークフローに組み込んでいきます。 ワークフローを記述するファイルを作成<code>.github/workflows/ci-gitleaks.yml</code>をリポジトリに置きます。以下のようにファイルを編集します。<pre><code>name: CI-gitleaks
on:
 push:　// 1.
jobs:
 asciidoctor_job:
 runs-on: self-hosted
 name: Scan secrets using gitleaks
 steps:
 - name: Check out code
 uses: actions/checkout@v3 // 2.
 - name: gitleaks
 run: |
 gitleaks detect -v --redact // 3.</code></pre>こちらの内容は<ol><li>プッシュしたときに</li><li>リポジトリを引っ張ってきて</li><li>gitleaksコマンドで検出するよ</li></ol>というものです。 動作確認次は機密情報がソースコードに無い状態でgitleaksが動くことを確認します。まずはコミット<pre><code>$ git add .
$ git commit -m 'テスト'
 ○
 │╲
 │ ○
 ○ ░
 ░ gitleaks

8:32AM INF scan completed in 605ms
8:32AM INF no leaks found</code></pre> 次にプッシュします。<pre><code>$ git push origin feature/gitleaks</code></pre>無事にプッシュ後、GithubActionsのワークフロー上でgitleaksコマンドが実行されていることが確認できました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3b5d669f11af4381b632eb136a3ae6c0/Untitled.png" alt="">

git push時にハードコーディングがないかをチェックする方法

<ul><li>gitleaksとは、機密情報をハードコードすることを防ぐ静的解析ツールである。</li><li><code>husky</code>というライブラリを使用することで、コミット時のハードコードを自動検出することができる。</li><li>GithubActionsのワークフローに組み込むことで、プッシュ時のハードコードを自動検出することができる。</li></ul> 何事もダブルチェックが大事ですね。

機密情報の漏洩を防ごう！～gitleaksの運用方法～

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c38e31d48b89483994121a397960e31f/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c81a04c0dd554f2caca8a3a45fbb7a36/Screenshot%20from%202024-04-19%2001-07-56.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b3a756028d65467fbed31c31726ec1d0/Screenshot%20from%202024-04-19%2021-45-31.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/fc2d78eb63284e3c8761d846bd09316c/Screenshot%20from%202024-04-17%2023-39-52.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/9a37ba0f0285471b895ed33f60a68f79/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/149388bf8cd1483988cec54829a694c6/Screenshot%20from%202024-04-17%2023-41-34.png" alt="">APIの疎通を確認したいだけなので今回はレスポンスをそのまま貼ってます。

成果物

図にするまでもないほど単純ですがインフラ構成図は以下のとおりです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/03dcccc7c27b48fea22130c63db88996/image.png" alt="">NextJSアプリはAmplifyでホスティングしました。下のAPI Gateway + Lambdaは自作のAPIで、前回までで使っていたMicropost APIのインフラをそのまま活用します。

インフラ

設計

雛形アプリには元々External APIとして<code>read:shows</code>というスコープが必要なAPIが定義されています。今回は追加で<code>read:microposts</code>というスコープを要求する自作のAPIを認可して呼んでみようと思います。 IDトークンのaudはクライアントアプリケーション（今回であればNextJSアプリ）ですがアクセストークンのaudは<code>AUTH0_AUDIENCE</code>環境変数で設定したものになります。 注意点としてAuth0のアクセストークンのaudは一つしか取れないようです（userinfoエンドポイント用のものを除いて）。複数のAPIを使いたい場合はどうすればいいかというと、audは共通のものを使い、scopeで区切ればいいみたいです。（<a href="https://zenn.dev/tatsuyasusukida/articles/auth0-multiple-api" target="_blank" rel="noopener noreferrer">こちら</a>の記事を参考にさせていただきました）今回は、<code>my-custom-api</code>というaud(API)を登録し要求するスコープとして<code>read:shows read:microposts</code>を定義しました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b5bcada393f340daadc03efd81a3aaef/image.png" alt="">

概要

<pre><code>diff --git a/app/api/microposts/route.js b/app/api/microposts/route.js
new file mode 100644
index 0000000..b16ab50
--- /dev/null
+++ b/app/api/microposts/route.js
@@ -0,0 +1,23 @@
+import { getAccessToken, withApiAuthRequired } from '@auth0/nextjs-auth0';
+import { NextResponse } from 'next/server';
+
+export const GET = withApiAuthRequired(async function shows(req) {
+&nbsp; try {
+&nbsp; &nbsp; const res = new NextResponse();
+&nbsp; &nbsp; const { accessToken } = await getAccessToken(req, res, {
+&nbsp; &nbsp; &nbsp; scopes: ['read:microposts']
+&nbsp; &nbsp; });
+&nbsp; &nbsp; const apiPort = process.env.API_PORT || 8000;
+&nbsp; &nbsp; const apiHost = process.env.API_HOST;
+&nbsp; &nbsp; const response = await fetch(`${apiHost}:${apiPort}/auth0/microposts`, {
+&nbsp; &nbsp; &nbsp; headers: {
+&nbsp; &nbsp; &nbsp; &nbsp; Authorization: `Bearer ${accessToken}`
+&nbsp; &nbsp; &nbsp; }
+&nbsp; &nbsp; });
+&nbsp; &nbsp; const shows = await response.json();
+
+&nbsp; &nbsp; return NextResponse.json(shows, res);
+&nbsp; } catch (error) {
+&nbsp; &nbsp; return NextResponse.json({ error: error.message }, { status: error.status || 500 });
+&nbsp; }
+});
diff --git a/app/microposts/page.jsx b/app/microposts/page.jsx
new file mode 100644
index 0000000..edf0e43
--- /dev/null
+++ b/app/microposts/page.jsx
@@ -0,0 +1,75 @@
+'use client';
+
+import React, { useState } from 'react';
+import { Button } from 'reactstrap';
+import { withPageAuthRequired } from '@auth0/nextjs-auth0/client';
+
+import Loading from '../../components/Loading';
+import ErrorMessage from '../../components/ErrorMessage';
+import Highlight from '../../components/Highlight';
+
+function External() {
+&nbsp; const [state, setState] = useState({ isLoading: false, response: undefined, error: undefined });
+
+&nbsp; const callApi = async () =&gt; {
+&nbsp; &nbsp; setState(previous =&gt; ({ ...previous, isLoading: true }));
+
+&nbsp; &nbsp; try {
+&nbsp; &nbsp; &nbsp; const response = await fetch('/api/microposts');
+&nbsp; &nbsp; &nbsp; const data = await response.json();
+
+&nbsp; &nbsp; &nbsp; setState(previous =&gt; ({ ...previous, response: data, error: undefined }));
+&nbsp; &nbsp; } catch (error) {
+&nbsp; &nbsp; &nbsp; setState(previous =&gt; ({ ...previous, response: undefined, error }));
+&nbsp; &nbsp; } finally {
+&nbsp; &nbsp; &nbsp; setState(previous =&gt; ({ ...previous, isLoading: false }));
+&nbsp; &nbsp; }
+&nbsp; };
+
+&nbsp; const handle = (event, fn) =&gt; {
+&nbsp; &nbsp; event.preventDefault();
+&nbsp; &nbsp; fn();
+&nbsp; };
+
+&nbsp; const { isLoading, response, error } = state;
+
+&nbsp; return (
+&nbsp; &nbsp; &lt;&gt;
+&nbsp; &nbsp; &nbsp; &lt;div className="mb-5" data-testid="external"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;h1 data-testid="external-title"&gt;Microposts&lt;/h1&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;div data-testid="external-text"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p className="lead"&gt;Ping an external API by clicking the button below&lt;/p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This will call a local API on port 3001 that would have been started if you run &lt;code&gt;npm run dev&lt;/code&gt;.
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; An access token is sent as part of the request's &lt;code&gt;Authorization&lt;/code&gt; header and the API will validate
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; it using the API's audience value. The audience is the identifier of the API that you want to call (see{' '}
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a href="https://auth0.com/docs/get-started/dashboard/tenant-settings#api-authorization-settings"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; API Authorization Settings
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/a&gt;{' '}
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; for more info).
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;/div&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;Button color="primary" className="mt-5" onClick={e =&gt; handle(e, callApi)} data-testid="external-action"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Ping API
+&nbsp; &nbsp; &nbsp; &nbsp; &lt;/Button&gt;
+&nbsp; &nbsp; &nbsp; &lt;/div&gt;
+&nbsp; &nbsp; &nbsp; &lt;div className="result-block-container"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; {isLoading &amp;&amp; &lt;Loading /&gt;}
+&nbsp; &nbsp; &nbsp; &nbsp; {(error || response) &amp;&amp; (
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;div className="result-block" data-testid="external-result"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;h6 className="muted"&gt;Result&lt;/h6&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {error &amp;&amp; &lt;ErrorMessage&gt;{error.message}&lt;/ErrorMessage&gt;}
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {response &amp;&amp; &lt;Highlight&gt;{JSON.stringify(response, null, 2)}&lt;/Highlight&gt;}
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/div&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; )}
+&nbsp; &nbsp; &nbsp; &lt;/div&gt;
+&nbsp; &nbsp; &lt;/&gt;
+&nbsp; );
+}
+
+export default withPageAuthRequired(External, {
+&nbsp; onRedirecting: () =&gt; &lt;Loading /&gt;,
+&nbsp; onError: error =&gt; &lt;ErrorMessage&gt;{error.message}&lt;/ErrorMessage&gt;
+});
diff --git a/components/NavBar.jsx b/components/NavBar.jsx
index bf4eea4..c393d66 100644
--- a/components/NavBar.jsx
+++ b/components/NavBar.jsx
@@ -54,6 +54,11 @@ const NavBar = () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;External API
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/PageLink&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/NavItem&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;NavItem&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;PageLink href="/microposts" className="nav-link" testId="navbar-external"&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Microposts
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/PageLink&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/NavItem&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;)}
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/Nav&gt;</code></pre> 中身はほぼテンプレにあったExternal APIのコピペです。

フロントエンド

<pre><code>diff --git a/app.py b/app.py
index df4073e..c6791ef 100644
--- a/app.py
+++ b/app.py
@@ -6,6 +6,7 @@ import urllib
&nbsp;from datetime import datetime, timedelta, timezone
&nbsp;from chalicelib.models import Microposts
&nbsp;from chalicelib.utils import login
+import jwt
&nbsp;
&nbsp;
&nbsp;app = Chalice(app_name="XXXXXXXXXXXXXXXXXXX")
@@ -16,6 +17,7 @@ ssm = boto3.client("ssm")
&nbsp;CLIENT_ID = ssm.get_parameter(Name="/google_oauth/client_id")["Parameter"]["Value"]
&nbsp;CLIENT_SECRET = ssm.get_parameter(Name="/google_oauth/client_secret")["Parameter"]["Value"]
&nbsp;REDIRECT_URI = ssm.get_parameter(Name="/google_oauth/redirect_uri")["Parameter"]["Value"]
+AUTH0_CLIENT_ID = ssm.get_parameter(Name="/auth0/client_id")["Parameter"]["Value"]
&nbsp;
&nbsp;
&nbsp;@app.route("/get_token", methods=["POST"], cors=CORSConfig(allow_origin="https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"))
@@ -112,3 +114,33 @@ def _parse_schedule(schedule_str):
&nbsp; &nbsp; &nbsp;summary = " ".join(parts[5:])
&nbsp;
&nbsp; &nbsp; &nbsp;return start, end, summary
+
+
+@app.route("/auth0/microposts", methods=["GET"])
+def get_micropost_for_auth0():
+&nbsp; &nbsp; if "Authorization" not in app.current_request.headers:
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body=None, status_code=401)
+
+&nbsp; &nbsp; access_token = app.current_request.headers["Authorization"].removeprefix("Bearer ")
+
+&nbsp; &nbsp; jwks_client = jwt.PyJWKClient("https://dev-XXXXXXXXXXXXXXXXXXXXX.us.auth0.com/.well-known/jwks.json")
+&nbsp; &nbsp; try:
+&nbsp; &nbsp; &nbsp; &nbsp; signing_key = jwks_client.get_signing_key_from_jwt(access_token)
+&nbsp; &nbsp; &nbsp; &nbsp; payload = jwt.decode(
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; access_token,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; signing_key.key,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; algorithms=["RS256"],
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; audience=AUTH0_CLIENT_ID,
+&nbsp; &nbsp; &nbsp; &nbsp; )
+&nbsp; &nbsp; except Exception as e:
+&nbsp; &nbsp; &nbsp; &nbsp; app.log.error(e)
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body=None, status_code=401)
+
+&nbsp; &nbsp; # scopeの検証
+&nbsp; &nbsp; if "read:microposts" not in payload["scope"].split():
+&nbsp; &nbsp; &nbsp; &nbsp; app.log.error("insufficient scope")
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body=None, status_code=401)
+
+&nbsp; &nbsp; posts = Microposts.query(payload.get("sub"))
+&nbsp; &nbsp; res = [post.to_simple_dict() for post in posts]
+&nbsp; &nbsp; return Response(body=res, status_code=200)</code></pre>

バックエンド

API連携の実装

Auth0においてはIDトークンだけでなくアクセストークンも実態は署名付きJWTです。実装していてそれぞれのpayloadを参照したいことが結構あると思ったので以下に記載しておきます。 IDトークンのpayload<pre><code>{
&nbsp; "nickname": "XXXXXXX",
&nbsp; "name": "XXXXXXXXXXXXXXX",
&nbsp; "picture": "https://s.gravatar.com/avatar/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.png",
&nbsp; "updated_at": "2024-04-18T14:31:52.952Z",
&nbsp; "iss": "https://dev-XXXXXXXXXXXXXXXXXXXXXXXXXXX.us.auth0.com/",
&nbsp; "aud": "XXXXXXXXXXXXXXXXXXXXXXXX",
&nbsp; "iat": 1713450713,
&nbsp; "exp": 1713486713,
&nbsp; "sub": "auth0|XXXXXXXXXXXXXXXXXXXXXXXXXX",
&nbsp; "sid": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
&nbsp; "nonce": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}</code></pre> アクセストークンのpayload<pre><code>{
&nbsp; "iss": "https://dev-XXXXXXXXXXXXXXXXXXXXXXXX.us.auth0.com/",
&nbsp; "sub": "auth0|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXx",
&nbsp; "aud": [
&nbsp; &nbsp; "my-custom-api",
&nbsp; &nbsp; "https://dev-XXXXXXXXXXXXXXXXXXXXXX.us.auth0.com/userinfo"
&nbsp; ],
&nbsp; "iat": 1713452513,
&nbsp; "exp": 1713538913,
&nbsp; "scope": "openid profile read:shows read:microposts",
&nbsp; "azp": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}</code></pre>

Auth0のアクセストークンとIDトークン

今回はAuth0環境の構築から自作のAPIを投げてみるまで試してみました。 迷ったのはAPIでユーザを検証するときにIDトークンを使うかアクセストークンを使うかです。APIのクライアントが確実に限定される場合はIDトークンのほうがユーザが認証されていることが保証されるのでセキュリティ的なことを考えてもいいと思いますが、アクセストークンを使うのでも使い方としては正しいと思います。（むしろ投稿アプリの使用をユーザが認可したという意味になるのでアクセストークンの方が本来の目的にあってそうな気がします）ただその考え方を推し進めると全てのバックエンドとのやり取りはアクセストークンを使えばいいとなって逆にIDトークンいらなくない？とちょっと思いましたが、見ての通りIDトークンにはユーザ名やアバターなどアプリの見た目をユーザのためにカスタマイズするのに必要ですし（userinfoエンドポイントにアクセスすればいいじゃんという話もありますが・・・）、アクセストークンでは認証の証明にはならないためアプリ側でIDトークンの検証は行うべきだと思います。

さいごに

Auth0環境を構築して自作のAPIと連携してみた

最もセキュリティレベルが高いのは、都度認証でしょう。また、バックエンドから認証エラーが返ってきたときにログイン画面にリダイレクトすればいいだけなので、実装的にも最も簡単だと思われます。ただ、当然のことながらIDトークンの有効期限が切れるたびに認証を突破しなければいけないため、UX的には最も劣る方法でもあります。 次にトークンをリフレッシュする方法を考えます。これなら有効期限が切れてもユーザの手を煩わせることもありません。フロント側でリフレッシュトークンを持っておいて、バックエンドから認証エラーが返ってきたときにトークンエンドポイントに対してリフレッシュトークンを送信し、新しいIDトークンを受け取ります。ただこの場合、リフレッシュトークンが万が一漏れた場合に他人になりすまされてしまいます。フロント側ではリフレッシュトークンを安全に保管することはできません。 バックエンド側でトークンを保管することを考えます。そうするとフロントとバックエンドでセッションを共有するための別の要素が必要になってきます。ログインに成功したら、バックエンドでセッションIDを発行し、トークン3セットと紐付けておきます。レスポンスとしてはトークン3セットの代わりにセッションIDを返すようにしましょう。そうすると、フロントはIDトークンの有効期限など考えずに、単純にセッションIDをCookieに保存しておき、毎回のリクエストに含めるだけで良くなります。IDトークンの有効期限が来た場合は、よしなにバックエンドでトークンをリフレッシュし、新しいトークンに交換しておきます。ただこの場合も、セッションIDが漏れた場合になりすまされてしまいます。結局、リフレッシュトークンがセッションIDに置き換わっただけで、本質的には何も変わっていません。

基本的な方針の比較

リフレッシュトークンもセッションIDの違いについて考えてみます。まず、リフレッシュトークンには有効期限がありますがセッションIDにはありません。しかし、セッションIDをCookieで保存するなら有効期限は設定できます。次に、セッションIDはリクエストのたびに送るものですが、リフレッシュトークンはトークンの有効期限が切れた場合のみ送るものです。なので、ネットワークを経由する頻度としてはリフレッシュトークンのほうが圧倒的に少ないと言えます。最後に、漏洩した場合のリスクですが、セッションIDについては明示的にログアウトしない限り有効です。リフレッシュトークンについて言えば、基本的に1回使ったら古いものは使えないはずです。※リフレッシュトークンの再利用はできないようにすべきですが、OAuth2.0の仕様として<a href="unsafe:決められているわけではない">決められているわけではない</a>ようです。<blockquote>例えば, 認可サーバーはアクセストークンリフレッシュレスポンスの都度新しいリフレッシュトークンを発行するリフレッシュトークンローテーションを採用することができる.&nbsp;</blockquote> 総合的に見て、単なるセッションIDよりもリフレッシュトークンのほうがセキュリティレベルが高いような気がしてきました。

リフレッシュトークンとセッションIDの比較

考察

Googleの場合には、インプリシットフローではリフレッシュトークンを取得することができませんでした。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/11a4132c62f14a59ac1e6a3f79d451ad/Screenshot%20from%202024-04-12%2022-59-34.png" alt="">やはりURLフラグメントで丸見えになってしまうからでしょうか。リフレッシュトークンは有効期限が長く漏洩した場合のダメージが大きいため、インプリシットフローではそもそも禁止されているものと思われます。なので、その場合は都度認証しか手段がないですね。

インプリシットフローとリフレッシュトークン

上の比較検討のところで、<blockquote>リフレッシュトークンについて言えば、基本的に1回使ったら古いものは使えないはずです。</blockquote>と書きましたが、本当にそうでしょうか？試しにGoogleの認可サーバが対応しているかどうか試してみましょう。 1回目の使用<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/246b3998ed614b8eacba838023775956/Screenshot%20from%202024-04-12%2023-13-28.png" alt=""> 2回目の使用<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/81b0cac66f4d4207855cedff3dffd7af/Screenshot%20from%202024-04-12%2023-15-44.png" alt=""> 普通に使えちゃってますね・・・意外でした。 ユーザがもう一度認可した場合は、古いリフレッシュトークンは利用できるんでしょうか？（再度認可しました） <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/5796533aa26f414896e1d475e8de755b/Screenshot%20from%202024-04-12%2023-19-44.png" alt="">普通に使えちゃってますね・・・これだと、セッションIDを使うのとあまり変わらないかもしれないです。 後になって気づいたのですが、トークンリフレッシュレスポンスにリフレッシュトークンは含まれていませんでした。つまり、元々最初に発行されたリフレッシュトークンを使いまわすことをあえて意図しているようです。リフレッシュトークンの有効期限について調べてみましたが、明確な記述は見つかりませんでした。<a href="https://groups.google.com/g/google-apps-api-japan/c/kvKDfaQfvvI" target="_blank" rel="noopener noreferrer">かなり長く設定されているようだ、みたいな話</a>もあるみたいです。

リフレッシュトークンのローテーション検証

演習

以下、あくまでも自分の意見ですがまとめました。<ul><li>ユーザがいないときにアクセストークンを利用するユースケース(毎日特定の時間にGoogleドライブにアクセスするなど)がないのであれば、都度認証が最も望ましい<ul><li>1時間毎だと煩わしいのであれば、3時間毎にするとか。セキュリティ面とのバランスでチューニングする</li></ul></li><li>都度認証が許容できないのであれば、リフレッシュトークンをフロント側にもたせるのもアリ</li></ul>

「Googleでログイン」を実装してみた〜トークンリフレッシュ編〜

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/78e8262c26564c02ab305e7d3d4000d1/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/082a3f9c7dca45838fe7014a999e7dd6/Screenshot%20from%202024-04-09%2023-05-30.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/44906d0330a94ceb8beefb33a698ac34/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/428d42b6fd7848ca8fe7eabe1600744d/Screenshot%20from%202024-04-09%2023-08-06.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/da3a5b5b5dbe4870bbafef611dd64bcd/Screenshot%20from%202024-04-09%2023-10-12.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/67678995983d475c817647e078d1b046/Screenshot%20from%202024-04-09%2023-11-42.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/94214a245aef40648d0dfc89fc36f725/Screenshot%20from%202024-04-09%2023-13-18.png" alt="">"yyyy/mm/dd hh:MM:ss ~ yyyy/mm/dd hh:MM:ss hogehoge"というパターンの投稿がされた場合に、予定に関する投稿とみなしてGoogleカレンダーに登録する仕様です。

実装のポイントとしては、<ul><li>Googleカレンダーへのアクセス権限が欲しいので、OAuthのスコープにGoogleカレンダーの読み書き権限を追加する</li><li>上記の権限が付与されたアクセストークンを使ってGoogleカレンダーAPIにアクセスしたいので、投稿APIのリクエストボディにアクセストークンを追加する</li></ul>というところです。ベースの実装ができているのでほんの少しの修正だけで実現できます。

ポイント

<pre><code>diff --git a/src/routes/+page.svelte b/src/routes/+page.svelte
index 910dc9d..ad79e35 100644
--- a/src/routes/+page.svelte
+++ b/src/routes/+page.svelte
@@ -10,7 +10,7 @@
&nbsp;		const params = {
&nbsp;			response_type: 'code',
&nbsp;			client_id: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com',
-			scope: 'openid profile email',
+			scope: 'openid profile email https://www.googleapis.com/auth/calendar',
&nbsp;			redirect_uri: 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/callback',
&nbsp;			state: Math.random().toString(32).substring(2),
&nbsp;			nonce: Math.random().toString(32).substring(2)
@@ -33,7 +33,7 @@
&nbsp;		const params = {
&nbsp;			response_type: 'token id_token',
&nbsp;			client_id: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com',
-			scope: 'openid profile email',
+			scope: 'openid profile email https://www.googleapis.com/auth/calendar',
&nbsp;			redirect_uri: 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/implicit/callback',
&nbsp;			state: Math.random().toString(32).substring(2),
&nbsp;			nonce: Math.random().toString(32).substring(2)
diff --git a/src/routes/microposts/+page.svelte b/src/routes/microposts/+page.svelte
index 7dbfe73..8bad0ee 100644
--- a/src/routes/microposts/+page.svelte
+++ b/src/routes/microposts/+page.svelte
@@ -27,7 +27,7 @@
&nbsp;
&nbsp; &nbsp; &nbsp;async function post() {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// 投稿
-&nbsp; &nbsp; &nbsp; &nbsp; await axios.post('https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/api/microposts', {content: content}, {headers: {Authorization: `Bearer ${id_token}`}});
+&nbsp; &nbsp; &nbsp; &nbsp; await axios.post('https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/api/microposts', {content: content, access_token: access_token}, {headers: {Authorization: `Bearer ${id_token}`}});
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// リロード
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;micropostRes = await axios.get('https://nfk13r40e6.execute-api.ap-northeast-1.amazonaws.com/api/microposts', {headers: {Authorization: `Bearer ${id_token}`}});
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;console.log(micropostRes);</code></pre>

<pre><code>diff --git a/app.py b/app.py
index bd01a93..df4073e 100644
--- a/app.py
+++ b/app.py
@@ -3,6 +3,7 @@ import logging
&nbsp;import requests
&nbsp;import boto3
&nbsp;import urllib
+from datetime import datetime, timedelta, timezone
&nbsp;from chalicelib.models import Microposts
&nbsp;from chalicelib.utils import login
&nbsp;
@@ -57,6 +58,27 @@ def post():
&nbsp; &nbsp; &nbsp;micropost = user.post(req["content"])
&nbsp; &nbsp; &nbsp;micropost.save()
&nbsp;
+&nbsp; &nbsp; if "access_token" in req:
+&nbsp; &nbsp; &nbsp; &nbsp; start, end, summary = _parse_schedule(req["content"])
+&nbsp; &nbsp; &nbsp; &nbsp; if start and end and summary:
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; app.log.info(f"googleカレンダーに予定({summary})を作成します")
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; token = req["access_token"]
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; res = requests.post(
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "https://www.googleapis.com/calendar/v3/calendars/primary/events",
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; headers={"Authorization": f"Bearer {token}"},
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; json={
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "summary": summary,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "description": "これはサンプルアプリで作成した予定です",
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "start": {"dateTime": start.isoformat()},
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "end": {"dateTime": end.isoformat()},
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; },
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; )
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if res.status_code &gt;= 300:
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; app.log.error(res.json())
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return Response(body={"message": "server error"}, status_code=500)
+
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; app.log.info(f"googleカレンダーに予定({summary})を作成しました")
+
&nbsp; &nbsp; &nbsp;return Response(body={"posted_at": micropost.postedAt.isoformat()}, status_code=201)
&nbsp;
&nbsp;
@@ -70,3 +92,23 @@ def get_list():
&nbsp; &nbsp; &nbsp;posts = Microposts.query(user.id)
&nbsp; &nbsp; &nbsp;res = [post.to_simple_dict() for post in posts]
&nbsp; &nbsp; &nbsp;return Response(body=res, status_code=200)
+
+
+def _parse_schedule(schedule_str):
+&nbsp; &nbsp; # 文字列をスペースで分割して情報を取得
+&nbsp; &nbsp; parts = schedule_str.split()
+
+&nbsp; &nbsp; if len(parts) &lt; 5 or parts[2] != "~":
+&nbsp; &nbsp; &nbsp; &nbsp; return None, None, None
+
+&nbsp; &nbsp; # 日付と時間をパースしてdatetimeオブジェクトに変換
+&nbsp; &nbsp; start_str = f"{parts[0]} {parts[1]}"
+&nbsp; &nbsp; end_str = f"{parts[3]} {parts[4]}"
+
+&nbsp; &nbsp; start = datetime.strptime(start_str, "%Y/%m/%d %H:%M").replace(tzinfo=timezone(timedelta(hours=9)))
+&nbsp; &nbsp; end = datetime.strptime(end_str, "%Y/%m/%d %H:%M").replace(tzinfo=timezone(timedelta(hours=9)))
+
+&nbsp; &nbsp; # サマリを取得
+&nbsp; &nbsp; summary = " ".join(parts[5:])
+
+&nbsp; &nbsp; return start, end, summary</code></pre>

今回はGoogleカレンダー権限をスコープに追加してアクセスする実装を試してみました。今回はAPIの中で直接GoogleカレンダーAPIを叩いてしまっていますが、Googleカレンダーに登録するまでユーザを待たせてしまうのも微妙なので、非同期で登録するようにしたほうがいいと思いました。その場合は非同期キューにアクセストークンを含ませたリクエストを登録する形になりそうです。今回、IDトークンはAuthorizationヘッダに含ませていますが、アクセストークンはリクエストボディに含ませました。なんか不格好な気がしますが、一般的なOIDCを利用したAPIの設計はどうするのが普通なんでしょうか・・・ 今後やってみたいこととしては、<ul><li>トークンのリフレッシュに対応する</li><li>ログアウトに対応する</li><li>他のIDPを利用する</li></ul>などがあります。際限なく出てきますね・・・また実装でき次第記事にしようと思います。

<a href="https://developers.google.com/calendar/api/v3/reference?hl=ja" target="_blank" rel="noopener noreferrer">GoogleカレンダーAPIリファレンス</a>

参考

「Googleでログイン」を実装してみた（その４）

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/733233b1b8884371bcb20181d0911fa7/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/2a750075287c4dbb96059adc4ed93155/Screenshot%20from%202024-04-01%2022-59-54.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/cf213cf0d3d0442f8f62e6ad63e88130/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ef375ca6f364478397e86f9703993e61/Screenshot%20from%202024-04-01%2023-02-53.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d3a28bba2ba843908323d1f8b0ac1526/Screenshot%20from%202024-04-01%2023-12-44.png" alt="">短文を投稿するのと自分の投稿を一覧表示するシンプルな画面を作りました。ちなみに、投稿画面だけちょっといい感じのスタイルになってるのはChatGPTさんに作ってもらったからです。html+cssだったらかなり上出来でいいなと思いました。

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/03a5facc8c3f4d91bf2cad40c35d2487/google_oauth_example_dynamo.png" alt="">追加の要素としては、データ永続化層が必要なので、DynamoDBが増えたというところだけです。

認証（IDトークンを取得する）フローについては前回までの内容と同じなので省略します。認証後のフローとしては、IDトークン・アクセストークンをセッションストレージに保存し、それを持ってアプリ固有の保護対象リソースにアクセスするAPIを呼び出します。今回は投稿機能ということで、投稿内容を一覧取得するAPIと、投稿するAPIの2本を作成しました。 以下は投稿時のフロー図です。認可サーバのユーザ情報取得APIと投稿API、投稿一覧取得APIの計3本のAPIを叩きます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/65d87407f98545dcaa8a7fedd281e50e/oauth2.0_dynamo.png" alt="">

フロー図

Users<ul><li>issuer（パーティションキー）</li><li>subject（ソートキー）</li><li>id</li><li>createdAt</li><li>updatedAt</li></ul> Microposts<ul><li>userId（パーティションキー）</li><li>postedAt（ソートキー）</li><li>content</li><li>createdAt</li><li>updatedAt</li></ul> Usersの用途としては、IDトークンのissとsubからアプリ固有のidにマッピングするのが目的です。IDトークンの仕様上、issとsubの組み合わせでグローバルに一意になることが保証されるためです。こうしておくことで、もし他のIDProviderが増えても問題ない作りになっています。 Micropostsが投稿を保存するためのテーブルです。主にユーザに紐づく投稿を一覧取得する目的なので、userId, postedAtの複合主キーとしました。ただ、投稿を一意に指定できるIDもあったほうが良かったかもしれません。今の形だと、例えば特定の投稿を更新したい場合に、「自分が投稿した投稿日時yyyy-MM-dd hh:mm:ssの投稿を更新してください」のようなぎこちない指定方法になってしまうためです。

テーブル設計

src/routes/callback/+page.svelte<pre><code>@@ -1,4 +1,5 @@
&nbsp;&lt;script lang="ts"&gt;
+	import { goto } from '$app/navigation';
&nbsp;	import { error } from '@sveltejs/kit';
&nbsp;	import axios, { type AxiosResponse } from 'axios';
&nbsp;	import { onMount } from 'svelte';
@@ -22,6 +23,10 @@
&nbsp;			code: queryParams.code,
&nbsp;		});
&nbsp;
+		// トークンをセッションストレージに保存
+		sessionStorage.setItem('access_token', res.data.access_token);
+		sessionStorage.setItem('id_token', res.data.id_token);
+
&nbsp;		// userinfoエンドポイントにアクセス
&nbsp;		const discoverDoc = JSON.parse(sessionStorage.getItem('discoverDoc') ?? '');
&nbsp;		userInfoRes = await axios.get(discoverDoc.userinfo_endpoint, {headers: {Authorization: `Bearer ${res.data.access_token}`}});
@@ -32,6 +37,7 @@
&nbsp;{#if userInfoRes}
&nbsp;	&lt;h1&gt;{userInfoRes.data?.name}&lt;/h1&gt;
&nbsp;	&lt;img src={userInfoRes.data?.picture} alt="facePicture" /&gt;
+	&lt;button on:click={() =&gt; goto("/microposts")}&gt;投稿&lt;/button&gt;
&nbsp;{:else}
&nbsp;	&lt;h1&gt;ログインしています...&lt;/h1&gt;
&nbsp;{/if}</code></pre> src/routes/microposts/+page.svelte<pre><code>&lt;script lang="ts"&gt;
 import axios, { type AxiosResponse } from 'axios';
 import dayjs from 'dayjs';
 import { onMount } from "svelte";

 let access_token: string;
 let id_token: string;
 let userInfoRes: AxiosResponse;
 let micropostRes: AxiosResponse;
 let content: string;

 onMount(async () =&gt; {
 // セッションストレージからトークンを取得
 access_token = sessionStorage.getItem('access_token') ?? '';
 id_token = sessionStorage.getItem('id_token') ?? '';

 // userinfoエンドポイントにアクセス
 const discoverDoc = JSON.parse(sessionStorage.getItem('discoverDoc') ?? '');
 userInfoRes = await axios.get(discoverDoc.userinfo_endpoint, {headers: {Authorization: `Bearer ${access_token}`}});
 console.log(userInfoRes);

 // 投稿一覧取得APIにアクセス
 micropostRes = await axios.get('https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/microposts', {headers: {Authorization: `Bearer ${id_token}`}});
 console.log(micropostRes);
 });

 async function post() {
 // 投稿
 await axios.post('https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/microposts', {content: content}, {headers: {Authorization: `Bearer ${id_token}`}});
 // リロード
 micropostRes = await axios.get('https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/microposts', {headers: {Authorization: `Bearer ${id_token}`}});
 console.log(micropostRes);
 // インプットを空にする
 content = ''
 }
&lt;/script&gt;

&lt;h1&gt;投稿&lt;/h1&gt;
{#if userInfoRes &amp;&amp; micropostRes}
&lt;div style="max-width: 600px; margin: 20px auto;"&gt;
 {#each micropostRes.data as micropost}
 &lt;div style="border-bottom: 1px solid #ccc; padding: 10px 0; display: flex; align-items: center;"&gt;
 &lt;img style="width:50px; height:50px; border-radius:50%; margin-right:10px;" src={userInfoRes.data.picture} alt="facePicture"&gt;
 &lt;div style="flex-grow: 1;"&gt;
 &lt;h3 style="margin:0; font-size:18px;"&gt;{userInfoRes.data.name}&lt;/h3&gt;
 &lt;p style="margin:5px0; font-size:14px; color:#555;"&gt;{micropost.content}&lt;/p&gt;
 &lt;p style="margin:5px0; font-size:14px; color:#555;"&gt;{dayjs(micropost.postedAt).format('YYYY-MM-DD HH:mm:ss')}&lt;/p&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 {/each}
 &lt;div style="padding: 10px 0; display: flex; align-items: center;"&gt;
 &lt;div style="flex-grow: 1;"&gt;
 &lt;input style="display: inline-block; width: calc(100% - 6em);" type="text" bind:value={content} /&gt;
 &lt;button on:click={post}&gt;投稿&lt;/button&gt;
 &lt;/div&gt;
 &lt;/div&gt;
&lt;/div&gt;
{/if}</code></pre>

app.py<pre><code>@@ -3,6 +3,8 @@ import logging
&nbsp;import requests
&nbsp;import boto3
&nbsp;import urllib
+from chalicelib.models import Microposts
+from chalicelib.utils import login
&nbsp;
&nbsp;
&nbsp;app = Chalice(app_name="XXXXXXXXXXXXXXXXX")
@@ -39,3 +41,32 @@ def index():
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return Response(body={"message": "server error"}, status_code=500)
&nbsp;
&nbsp; &nbsp; &nbsp;return res.json()
+
+
+@app.route("/microposts", methods=["POST"], cors=CORSConfig(allow_origin="https://XXXXXXXXXXXXXXXXXXXXXXXXX"))
+def post():
+&nbsp; &nbsp; try:
+&nbsp; &nbsp; &nbsp; &nbsp; user = login(app, CLIENT_ID)
+&nbsp; &nbsp; except Exception:
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body={"message": "server error"}, status_code=500)
+
+&nbsp; &nbsp; req = app.current_request.json_body or {}
+&nbsp; &nbsp; if "content" not in req:
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body={"message": "server error"}, status_code=500)
+
+&nbsp; &nbsp; micropost = user.post(req["content"])
+&nbsp; &nbsp; micropost.save()
+
+&nbsp; &nbsp; return Response(body={"posted_at": micropost.postedAt.isoformat()}, status_code=201)
+
+
+@app.route("/microposts", methods=["GET"], cors=CORSConfig(allow_origin="https://XXXXXXXXXXXXXXXXXXXXXXX"))
+def get_list():
+&nbsp; &nbsp; try:
+&nbsp; &nbsp; &nbsp; &nbsp; user = login(app, CLIENT_ID)
+&nbsp; &nbsp; except Exception:
+&nbsp; &nbsp; &nbsp; &nbsp; return Response(body={"message": "server error"}, status_code=500)
+
+&nbsp; &nbsp; posts = Microposts.query(user.id)
+&nbsp; &nbsp; res = [post.to_simple_dict() for post in posts]
+&nbsp; &nbsp; return Response(body=res, status_code=200)</code></pre> chalicelib/utils/login.py<pre><code>import jwt
from chalice import Chalice
from chalicelib.models import Users


def login(app: Chalice, client_id: str) -&gt; Users:
 if "Authorization" not in app.current_request.headers:
 raise Exception

 id_token = app.current_request.headers["Authorization"].removeprefix("Bearer ")

 jwks_client = jwt.PyJWKClient("https://www.googleapis.com/oauth2/v3/certs")
 try:
 signing_key = jwks_client.get_signing_key_from_jwt(id_token)
 payload = jwt.decode(
 id_token,
 signing_key.key,
 algorithms=["RS256"],
 audience=client_id,
 )
 except Exception as e:
 app.log.error(e)
 raise Exception

 count = Users.count(payload["iss"], Users.subject == payload["sub"])
 if count == 0:
 u = Users(issuer=payload["iss"], subject=payload["sub"])
 u.save()

 return Users.get(payload["iss"], payload["sub"])</code></pre> 一旦app.pyにベタ書きで済ませたかったのですが、UsersのインスタンスをreturnしようとするとChaliceResponceでラッピングされてしまうようだったので、utilに切り出しました。

今回、IDトークンを利用する実装を行ったので、nonce検証に対応しました。nonce検証はインプリシットフローでは必須となっています。そもそもnonce検証の目的は、リプレイアタックへの対策です。リプレイアタックとは簡単に言うと、URLのフラグメントに設定されたトークンだけを別のトークンに置き換える攻撃のことです。インプリシットフローでは必須と書きましたが、その理由としてはURLにトークンが含まれるため、履歴などから簡単に抜き取れるためです。ただ、フロント実装はいくらでも手元で変更できるので、あまり対策になっていない気もします・・・あと、認可コードフローでもURLに認可コード含まれない？と一瞬思いましたが認可コードは1回しか使えないので使用済みのものを抜き取っても使えないですね。認可コードフロー強し。 src/routes/implicit/callback/+page.svelte<pre><code>@@ -22,6 +22,13 @@
&nbsp;			error(401, { message: 'Invalid state parameter.' });
&nbsp;		}
&nbsp;
+		// nonceの検証
+		const sessionNonce = sessionStorage.getItem('nonce');
+		const payload = JSON.parse(decodeURIComponent(atob(fragmentArgs.id_token.split('.')[1])));
+		if (sessionNonce != payload.nonce) {
+			error(401, { message: 'Invalid nonce parameter.' });
+		}
+
&nbsp;		// トークンをセッションストレージに保存
&nbsp;		sessionStorage.setItem('access_token', fragmentArgs.access_token);
&nbsp;		sessionStorage.setItem('id_token', fragmentArgs.id_token);</code></pre>

nonceに対応する

今回は、アプリ固有の機能として投稿機能を実装し、その中でIDトークンを利用するようになったことからnonceの検証にも対応しました。

「Googleでログイン」を実装してみた（その３）

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/55a5e7124d97406eb7560dca4d9a56d3/Screenshot%20from%202024-03-26%2022-18-30.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/14c358cc482e4e629a0e37c7a6042a0c/Screenshot%20from%202024-03-26%2022-20-00.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/41963139eece4a459bac601f42c9f7bc/Screenshot%20from%202024-03-26%2022-21-12.png" alt="">ぶっちゃけ見た目的にはほとんど何も変わってないです・・・

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/24752de02e534d318b401d8af6e17ec5/google_oauth_example_implicit.png" alt="">認可エンドポイントしか使用しないのでバックエンドは不要になりました。

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/1c656de1d3d3404a97999e442297218d/oauth2.0_implicit.png" alt="">認可コードフローの場合は認可エンドポイントから認可コードが返ってきて、それをアクセストークンと交換する必要があったのですが、インプリシットフローの場合は直接アクセストークンが返ってきます。前回よりもぐっとシンプルになりました。

認可コードフローが実装できればインプリシットフローはほぼ同じです。以下、フロント実装の差分です。<pre><code>diff --git a/src/routes/+page.svelte b/src/routes/+page.svelte
index 659e6e5..910dc9d 100644
--- a/src/routes/+page.svelte
+++ b/src/routes/+page.svelte
@@ -23,7 +23,31 @@
&nbsp;		const href = `${discoverRes.data.authorization_endpoint}?response_type=${params.response_type}&amp;client_id=${params.client_id}&amp;scope=${params.scope}&amp;redirect_uri=${params.redirect_uri}&amp;state=${params.state}&amp;nonce=${params.nonce}`;
&nbsp;		location.href = href;
&nbsp;	}
+
+	async function implicitLogin() {
+		// ディスカバリドキュメントを参照
+		const discoverRes = await axios.get('https://accounts.google.com/.well-known/openid-configuration');
+		sessionStorage.setItem('discoverDoc', JSON.stringify(discoverRes.data));
+
+		// 認可エンドポイントへのリクエストパラメータ設定
+		const params = {
+			response_type: 'token id_token',
+			client_id: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com',
+			scope: 'openid profile email',
+			redirect_uri: 'https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/implicit/callback',
+			state: Math.random().toString(32).substring(2),
+			nonce: Math.random().toString(32).substring(2)
+		};
+
+		sessionStorage.setItem('state', params.state);
+		sessionStorage.setItem('nonce', params.nonce);
+
+		// 認可エンドポイントへ遷移
+		const href = `${discoverRes.data.authorization_endpoint}?response_type=${params.response_type}&amp;client_id=${params.client_id}&amp;scope=${params.scope}&amp;redirect_uri=${params.redirect_uri}&amp;state=${params.state}&amp;nonce=${params.nonce}`;
+		location.href = href;
+	}
&nbsp;&lt;/script&gt;
&nbsp;
&nbsp;&lt;h1&gt;ログイン&lt;/h1&gt;
&nbsp;&lt;p&gt;&lt;button on:click={login}&gt;Googleでログイン&lt;/button&gt;&lt;/p&gt;
+&lt;p&gt;&lt;button on:click={implicitLogin}&gt;Googleでログイン(Implicit)&lt;/button&gt;&lt;/p&gt;
diff --git a/src/routes/implicit/callback/+page.svelte b/src/routes/implicit/callback/+page.svelte
new file mode 100644
index 0000000..efac8cb
--- /dev/null
+++ b/src/routes/implicit/callback/+page.svelte
@@ -0,0 +1,36 @@
+&lt;script lang="ts"&gt;
+	import { error } from "@sveltejs/kit";
+	import axios, { type AxiosResponse } from "axios";
+	import { onMount } from "svelte";
+	let userInfoRes: AxiosResponse;
+
+&nbsp; &nbsp; onMount(async () =&gt; {
+&nbsp; &nbsp; &nbsp; &nbsp; const fragment = window.location.hash;
+&nbsp; &nbsp; &nbsp; &nbsp; const keyValueArgs = fragment.substring(1).split('&amp;');
+&nbsp; &nbsp; &nbsp; &nbsp; let fragmentArgs: Record&lt;string, string&gt; = {};
+&nbsp; &nbsp; &nbsp; &nbsp; for (const keyValue of keyValueArgs) {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const [key, value] = keyValue.split('=');
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; fragmentArgs[decodeURIComponent(key)] = decodeURIComponent(value);
+&nbsp; &nbsp; &nbsp; &nbsp; }
+&nbsp; &nbsp; &nbsp; &nbsp; console.log(fragmentArgs);
+
+		// 送られてきたstateが一致しているか確認
+		const sessionState = sessionStorage.getItem('state');
+
+		if (fragmentArgs.state != sessionState) {
+			error(401, { message: 'Invalid state parameter.' });
+		}
+
+&nbsp; &nbsp; &nbsp; &nbsp; // userinfoエンドポイントにアクセス
+		const discoverDoc = JSON.parse(sessionStorage.getItem('discoverDoc') ?? '');
+		userInfoRes = await axios.get(discoverDoc.userinfo_endpoint, {headers: {Authorization: `Bearer ${fragmentArgs.access_token}`}});
+		console.log(userInfoRes);
+&nbsp; &nbsp; });
+&lt;/script&gt;
+
+{#if userInfoRes}
+	&lt;h1&gt;{userInfoRes.data?.name}&lt;/h1&gt;
+	&lt;img src={userInfoRes.data?.picture} alt="facePicture" /&gt;
+{:else}
+	&lt;h1&gt;ログインしています...&lt;/h1&gt;
+{/if}</code></pre>

設計も実装もシンプルなインプリシットフローは魅力的に見えてしまうのですが、OAuth2.0で推奨されているのは認可コードフローの方です。インプリシットフローではアクセストークンやIDトークンが直接コールバックエンドポイントのURLのフラグメントとして付与されます。URLフラグメントはブラウザの履歴に残るため、履歴を閲覧できる立場であれば過去に発行されたトークンを抜き取ることが簡単にできてしまいます。対策としては、トークンの有効期限を短めに設定することが重要だと思います。 他にもセキュリティ的に考慮すべき点がいくつかあるようですが、深掘っていくとそれだけでかなりのボリュームになりそうなので、別の機会に譲ろうと思います。

インプリシットフローのセキュリティホールについて

今回は、OIDCのインプリシットフローを実装してみました。実装してみて、認証コードフローをしっかりと押さえていればよりシンプルな形になっただけなのでかなりハードルが低いように思えました。

「Googleでログイン」を実装してみた（その２）

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b590b4bc231e423a9f3637ae996dae9f/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/bd7ce0a4b28c42168648346657a5b010/Screenshot%20from%202024-03-23%2018-20-57.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/9c676aa0560942bfaa9d600c65417704/image.png" alt="">↓<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/32d6a3e9b18549e4bb0e4b4f6c1fb69c/Screenshot%20from%202024-03-23%2018-23-11.png" alt="">たったのこれだけです。

今回は以下のようなインフラ構成で実現しました。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/81ae802b06b645568065fb11d864edf9/google_oauth_example.png" alt="">ざっくりと説明するとフロントエンドがCloudFront + S3で静的サイト配信しJSで認可コードを取得、バックエンドがAPI Gateway + Lambdaでフロントで取得した認可コードを使ってトークン取得を取得します。

図にするとこんな感じです。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b0ae281a05b04625a7f72893015b9b6b/oauth2.0_code_spa.png" alt=""> <ol><li>アプリのURLにアクセスするとCloudFrontからJSなどの静的コンテンツが返される</li><li>ブラウザ上のJSから、Googleの認可エンドポイントにアクセスする<ol><li>その際、リクエストにクライアントIDとコールバックURLを含める</li></ol></li><li>Googleの認可画面が表示されるので、ユーザが（ログインしていなければログインした上で）認可を行う</li><li>認可エンドポイントにアクセス時に渡していたコールバックURLにリダイレクトする<ol><li>その際、認可コードを受け取る</li></ol></li><li>ブラウザ上のJSから、API Gatewayに対してトークン取得リクエストを送る<ol><li>その際、リクエストに認可コードを含める</li></ol></li><li>API Gatewayからトークンエンドポイントにアクセスし、アクセストークンやIDトークンなどを受け取る</li><li>ブラウザ上のJSから、Googleのuserinfoエンドポイントにアクセスしユーザ情報を取得する<ol><li>その際、リクエストにアクセストークンを含める</li></ol></li></ol>

まず考えられるのは認可コードをバックエンドに送信していますが、このバックエンドはSSGからのリクエストを受け付ける必要がありパブリックアクセスを許容する必要があるので、どこからでもアクセスできてしまいます。そうすると攻撃者が総当り的に認可コードを大量に送ると、ユーザのアクセストークンを奪うことができてしまう可能性があるかなと思います。当然CORSは設定していますが、APIを直で叩く場合は関係ないです。ただ少なくとも使用済みの認可コードは使えなくなるので、実際にその攻撃が成功する可能性は極めて低いと思います。 他には、同じくフロント・バック通信のところで、リクエスト・レスポンスを平文でやり取りしているため、万が一通信が傍受されると同様にアクセストークンが奪われる可能性がありそうです。公開鍵暗号を使おうとしても結局フロントがSSGなので秘密鍵を安全に保管することができないと思います。ただ、Googleからはアクセストークンがそのまま送られてくるわけで、お門違いな心配をしているような気もします。

セキュリティ的にどうなのか考えてみる

セキュリティの点はすぐに結論がでなそうなのでじっくり考えようと思います。その他で今後やってみたいこととしては、<ul><li>インプリシットフローを試す</li><li>保護対象リソースを構築して実際にアプリ固有のユーザ情報を取得する</li><li>認可スコープを増やしてGoogleカレンダーなどにアクセスしてみる</li></ul>このあたりが実装できたらまた記事にしたいと思います。

ネクストアクション

フロントは個人的にシンプルで好きなsvelteを使っています。 src/routes/+page.svelte<pre><code>&lt;script lang="ts"&gt;
 import axios from "axios";

 async function login() {
 // ディスカバリドキュメントを参照
 const discoverRes = await axios.get('https://accounts.google.com/.well-known/openid-configuration');
 sessionStorage.setItem('discoverDoc', JSON.stringify(discoverRes.data));

 // 認可エンドポイントへのリクエストパラメータ設定
 const params = {
 response_type: 'code',
 client_id: 'XXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com',
 scope: 'openid profile email',
 redirect_uri: 'XXXXXXXXXXXXXXXXXXXXXXXXXX/callback',
 state: Math.random().toString(32).substring(2),
 nonce: Math.random().toString(32).substring(2)
 };

 sessionStorage.setItem('state', params.state);
 sessionStorage.setItem('nonce', params.nonce);

 // 認可エンドポイントへ遷移
 const href = `${discoverRes.data.authorization_endpoint}?response_type=${params.response_type}&amp;client_id=${params.client_id}&amp;scope=${params.scope}&amp;redirect_uri=${params.redirect_uri}&amp;state=${params.state}&amp;nonce=${params.nonce}`;
 location.href = href;
 }
&lt;/script&gt;

&lt;h1&gt;ログイン&lt;/h1&gt;
&lt;p&gt;&lt;button on:click={login}&gt;Googleでログイン&lt;/button&gt;&lt;/p&gt;</code></pre> src/routes/callback/+page.svelte<pre><code>&lt;script lang="ts"&gt;
 import { error } from '@sveltejs/kit';
 import axios, { type AxiosResponse } from 'axios';
 import { onMount } from 'svelte';
 let queryParams;
 let userInfoRes: AxiosResponse;

 onMount(async () =&gt; {
 // コールバックエンドポイントにリダイレクトしてきた際のクエリパラメータを取得
 const params = new URLSearchParams(window.location.search);
 queryParams = Object.fromEntries(params.entries());

 // 送られてきたstateが一致しているか確認
 const sessionState = sessionStorage.getItem('state');

 if (queryParams.state != sessionState) {
 error(401, { message: 'Invalid state parameter.' });
 }

 // バックエンドからトークン取得
 const res = await axios.post('https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/get_token', {
 code: queryParams.code,
 });

 // userinfoエンドポイントにアクセス
 const discoverDoc = JSON.parse(sessionStorage.getItem('discoverDoc') ?? '');
 userInfoRes = await axios.get(discoverDoc.userinfo_endpoint, {headers: {Authorization: `Bearer ${res.data.access_token}`}});
 console.log(userInfoRes);
 });
&lt;/script&gt;

{#if userInfoRes}
 &lt;h1&gt;{userInfoRes.data?.name}&lt;/h1&gt;
 &lt;img src={userInfoRes.data?.picture} alt="facePicture" /&gt;
{:else}
 &lt;h1&gt;ログインしています...&lt;/h1&gt;
{/if}</code></pre>

バックエンドは個人的に好きなScalaとかを使いたかったのですがCI/CDの構築に詰まったので一旦安定のpython(Chalice)で作りました<pre><code>from chalice import Chalice, Response, CORSConfig
import logging
import requests
import boto3
import urllib

app = Chalice(app_name="XXXXXXXXXXXXXXXXXX")
app.log.setLevel(logging.DEBUG)

ssm = boto3.client("ssm")

CLIENT_ID = ssm.get_parameter(Name="/google_oauth/client_id")["Parameter"]["Value"]
CLIENT_SECRET = ssm.get_parameter(Name="/google_oauth/client_secret")["Parameter"]["Value"]
REDIRECT_URI = ssm.get_parameter(Name="/google_oauth/redirect_uri")["Parameter"]["Value"]


@app.route("/get_token", methods=["POST"], cors=CORSConfig(allow_origin="https://XXXXXXXXXXXXXXXXXXXXXXXXXXX"))
def index():
 req = app.current_request.json_body or {}
 if "code" not in req:
 return Response(body={"message": "server error"}, status_code=500)

 body = {
 "code": req["code"],
 "client_id": CLIENT_ID,
 "client_secret": CLIENT_SECRET,
 "redirect_uri": REDIRECT_URI,
 "grant_type": "authorization_code",
 }
 encoded = urllib.parse.urlencode(body)
 res = requests.post(
 "https://oauth2.googleapis.com/token",
 headers={"Content-Type": "application/x-www-form-urlencoded"},
 data=encoded,
 )
 if res.status_code &gt;= 300:
 app.log.error(res.json())
 return Response(body={"message": "server error"}, status_code=500)

 return res.json()</code></pre>

(おまけ)実装

<ul><li><a href="https://amzn.asia/d/6KPSQnn" target="_blank" rel="noopener noreferrer">OAuth徹底入門</a></li><li><a href="https://amzn.asia/d/8c7FfOw" target="_blank" rel="noopener noreferrer">OpenID Connect入門</a></li></ul>

BuildersIO produced by YOKU

#セキュリティの記事一覧

今から考える量子コンピュータ時代

AWS S3 のウイルスチェックが変わる！？

AWS Cognito を使って SSO 認証してみた

機密情報の漏洩を防ごう！～gitleaksの運用方法～

Auth0環境を構築して自作のAPIと連携してみた

「Googleでログイン」を実装してみた〜トークンリフレッシュ編〜

「Googleでログイン」を実装してみた（その４）

「Googleでログイン」を実装してみた（その３）

「Googleでログイン」を実装してみた（その２）

「Googleでログイン」を実装してみた（その１）

Nuxt.jsをS3にデプロイしてCloudFront経由でアクセスする

【Go言語】go mod tidy, go generateでエラーが発生した時の対処法

【React】React Hook Formでフォーム分割して送信時にデータ結合する

#セキュリティ の記事一覧

今から考える量子コンピュータ時代

AWS S3 のウイルスチェックが変わる！？

AWS Cognito を使って SSO 認証してみた

機密情報の漏洩を防ごう！～gitleaksの運用方法～

Auth0環境を構築して自作のAPIと連携してみた

「Googleでログイン」を実装してみた〜トークンリフレッシュ編〜

「Googleでログイン」を実装してみた（その４）

「Googleでログイン」を実装してみた（その３）

「Googleでログイン」を実装してみた（その２）

「Googleでログイン」を実装してみた（その１）

#セキュリティの記事一覧