8
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

TypeScript + Express + Clean Architectureで作る!自作OAuth 2.0サーバーのバックエンド作成

Last updated at Posted at 2025-12-14

はじめに

OAuth 2.0が難しすぎて、何言っているの?ってなったので、簡単にバックエンドを自作してみました!今回は、TypeScriptとExpressをベースに、ドメイン駆動開発(DDD)を意識して開発しました。
今後、フロント部分の構築や、DB(PostgreSQLやCosmos DB)に移行していきたいと思います。

OAuth 2.0とは?

今回この記事を参考に自作を行いました。動作はほぼ一緒です。

今回作成したアプリ

今回以下のGitHubに作成しています。
(今回フロントの部分も作成しようとしたのですが、時間がたらずバックエンドだけの紹介にします💦)
https://github.com/Ryosuke06/testOAuth

my-auth-app/backendまでディレクトリを移動して、
npm install
npm run build
npm run srart
をターミナルで実行して起動してください。
今回自分は、Postmanを使用して、検証しています。
Postman:https://www.postman.com/
以下画像のように設定してください!

スクリーンショット 2025-12-15 7.29.53.png

{
    "client_id": "1",
    "state": "mystate",
    "scopes": ["read", "write"],
    "redirect_uri": "http://example.com",
    "response_type": "code",
    "password": "john",
    "approve": true,
    "login_id": "john"
}

この設定を行いSentボタンを押すと、上の画像のようになります。また、backend/dist/src/data/authorizationCodeStore.jsonの中に

{
  "6sNbOazQ": {
    "value": "6sNbOazQ",
    "userId": 1,
    "clientId": "1",
    "scopes": [
      "read",
      "write"
    ],
    "redirectUri": "http://example.com",
    "expiresAt": "2025-12-15T22:37:53.697Z"
  }
}

このようなものが作成されます。ここに記述してあるvalueの値が認可コードです。

次にアクセストークンの作成

画像のように設定してください
※codeの値は、authorizationCodeStore.jsonの中に記載されたvalueの値(今回だと6sNbOazQ)を入れてください。
スクリーンショット 2025-12-15 7.50.41.png
結果として、以下写真のようなアクセストークンが取得できたらOKです!
スクリーンショット 2025-12-15 7.54.37.png

技術スタック

  • 言語: TypeScript
  • フレームワーク: Express
  • DIコンテナ: tsringe
  • バリデーション: Zod
  • データストア: JSONファイル(学習用のため、簡易的にファイルシステムを使用)

アーキテクチャの全体像

関心事を分離するために下記のようなアーキテクチャの設計をしています。

src/
├── domain/         # ドメイン層(ビジネスロジック、エンティティ)
├── usecases/       # ユースケース層(アプリケーション固有のビジネスルール)
├── repositories/   # リポジトリインターフェース(データの入出力定義)
├── presentation/   # プレゼンテーション層(HTTPリクエストのハンドリング)
├── repositoryimpl/ # インフラ層(リポジトリの実装、今回はJSONファイル操作)
└── config/         # 設定(DIコンテナのセットアップなど)

このような構成により、将来的にデータストアをJSONファイルからDBに移行する場合でも。repositoryimplを再帰るだけで対応可能です。

DDDを導入したことによる利点

それぞれの層でロジックを分けることができる

それぞれの層が異なる役割をもちます。例えば、ユースケース層はドメインオブジェクトとリポジトリを組み合わせて、具体的なアプリケーションの機能を表現します。ここでは「ドメインロジック」そのものは書かず、手順の調整に徹します。実際にデータベースなどに保存することに関しては無関心なのです。

技術的負債の分離

将来的にデータの保存する方法を変更したいという場合でも、1ファイルの編集だけで、変更が可能です。
ドメイン層などには全く影響を与えないです。

テストの用意性

今回は、テストを記述していないですが、テストコードもそれぞれの層で作成することができます。

感想

新卒で入社してから、DDDで作成されたコードが読めるまでかなり時間がかかりました。また、認証と認可の違いなどわかなかったです。このように手を動かして作成してみるとわかってくることも多いですね!
コードは、リファクタなど必要なところ多いので、修正していきます💦

参考文献

8
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?