1. 本人で商品もあるとき
  2. ログインしていないとき
  3. 他人の商品を触ろうとしたとき
  4. 本人だが商品が無いとき
  5. ログインしていなければ商品の有無より先に401
コース一覧
Node.js入門
認証と認可

Node.js入門

Node.jsの実行モデル、npm、Expressによるルーティング、REST API設計、データベース接続、トランザクションを使った購入処理、トークン認証まで、バックエンド開発の基礎を、毎レッスン実際にコードを書き、フリマアプリのAPIを自分の手で作りながら学びます。

1
Node.jsとは
01. Node.jsとは15分
02. スクリプトを実行する15分
03. npmとは15分
04. package.json15分
05. npmスクリプト15分
06. つくる:プロジェクト始動20分
07. 第1章クイズ10分
2
モジュールと非同期の復習
01. import/export15分
02. ファイルを読み書きする15分
03. async/await復習15分
04. JSONの取り回し15分
05. つくる:データ層20分
06. 第2章クイズ10分
3
はじめてのサーバー
01. サーバーとリクエスト15分
02. Expressを導入する15分
03. ルーティング15分
04. JSONを返す15分
05. 開発の回し方15分
06. つくる:サーバー始動20分
07. 第3章クイズ10分
4
REST APIのきほん
01. RESTの考え方15分
02. 一覧を返す15分
03. 1件を返す15分
04. 登録を受ける15分
05. 更新と削除15分
06. ステータスコード15分
07. つくる:商品CRUD完成20分
08. 第4章クイズ10分
5
リクエスト処理と検証
01. クエリパラメータ15分
02. 並び替えとページング15分
03. 入力検証15分
04. ミドルウェア15分
05. エラーハンドリング15分
06. つくる:検索API完成20分
07. 第5章クイズ10分
6
データベース接続
01. DBにつなぐ15分
02. 一覧・詳細をDB化15分
03. 出品をDB化15分
04. SQLインジェクション20分
05. 更新・削除をDB化15分
06. 購入トランザクション20分
07. つくる:DB版fleama20分
08. 第6章クイズ10分
7
認証のきほん
01. 認証と認可15分
02. パスワードハッシュ15分
03. ログインとトークン15分
04. 保護ルート15分
05. 本人のものだけ15分
06. つくる:認証完備20分
07. 第7章クイズ10分
8
総合制作
01. fleama API完成20分
02. Reactと接続する20分
03. サーバーで常駐させる20分
04. 自由拡張20分
05. 完成と次のステップ15分

認証と認可

いまの fleama は誰でも操作できる

第6章までで、出品も購入も削除もできる API ができました。ですが問題があります。

誰が呼んでも通ります。 他人の商品を勝手に書き換えることも、消すこともできます。フリマとしては成り立ちません。

第7章では、この穴を塞ぎます。

2つの別々の問い

必要なことは 2 つあり、混ざりやすいので分けて覚えてください。

問い例
認証あなたは誰かログインして本人だと確かめる
認可それをしてよいか自分の商品だけ編集できる

認証が先で、認可が後です。誰だか分からないうちは、してよいかも判断できません。

順番に見ていく

出品を書き換える依頼が来たとき、確かめるのはこの順です。

プレーンテキスト

1. ログインしているか → していなければ 401 2. その商品の出品者か → 違えば 403 3. その商品は存在するか → 無ければ 404

401 と 403 の違い

どちらも「断る」ですが、意味が違います。

コード意味言い換えると
401誰だか分からないログインしてください
403誰かは分かるが、権限が無いあなたには許可されていません

401 はログインすれば通ります。403 はログインし直しても通りません。他人の商品は、誰としてログインしても他人の商品だからです。

この 2 つを取り違えると、受け取った側が「ログインし直せば直るのか」を判断できなくなります。

認証はミドルウェアの仕事

第5章で「共通処理は手前にまとめる」と学びました。認証はまさにそれです。

プレーンテキスト

リクエスト → 認証ミドルウェア → ルート

通してよければ next()、だめなら 401 を返して打ち切ります。next() を呼ばずに止めるのが正しい場面が、ここで出てきます。

手を動かす

演習では、いまの状態を確かめます。守られていない API に何が起きるのかを、自分の目で見てください。

要件

  1. user が空なら 401(ログインしていない)
  2. user が owner と違えば 403(権限が無い)
  3. exists が false なら 404、すべて問題なければ 200

入出力例

judge("田中", "田中", true) → 200 judge("", "田中", true) → 401 judge("鈴木", "田中", true) → 403 judge("田中", "田中", false) → 404 judge("", "田中", false) → 401

ヒント

確かめる順番が結果を変えます。まずログインしているかを見ます

誰だか分からないうちは、権限があるかも判断できません

最後のテストは、順番を間違えると 404 になってしまいます

生田 陸人
監修生田 陸人
ゆめさくエンジニア / 現役ソフトウェアエンジニア監修者プロフィールを見る →
編集 ゆめさく編集部·公開 2026/08/10

関連レッスン

  • パスワードハッシュ

    会員登録APIでハッシュ保存し、平文保存の危険を説明できるようになります。

  • ログインとトークン

    ログインAPIがトークンを返すようにし、トークンを発行できるようになります。

  • 保護ルート

    出品と購入をログイン必須にし、トークンが要るAPIを作れるようになります。

  • 本人のものだけ

    自分の出品だけ編集できるようにし、認可チェックを書けるようになります。

このレッスンに出てくる用語

意味があいまいなまま進んだ語は、ここから読み直せます。

  • エンドポイント「この URL を叩くとこの機能が動く」入口の住所
  • APIアプリ間でデータをやり取りする窓口
  • 認証「この人は本当に本人?」のチェック
  • 認可「この人はこの操作していい人?」のチェック
  • 判断YES/NO 分岐を表す菱形
  • ミドルウェアリクエストとレスポンスの間に挟まる処理関数。
  • 処理計算や代入を表す長方形
main.js
学習モード
エディタを読み込んでいます

メモ

認証と認可

⌘S で保存