認証＠認証/認可

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。

• https://hiroki-it.github.io/tech-notebook/

01. 認証とは

通信しているユーザーが誰であるかを特定する。

基本的に、認証の実装は認可に依存しない。

02. 認証の種類

HTTP認証

• https://hiroki-it.github.io/tech-notebook/security/security_auth_authentication_http.html

Form認証 (Cookieベースの認証)

▼ Form認証とは

認証時に、Cookieヘッダー値を使用する認証スキームのこと。

『Cookieベースの認証』ともいう。

ステートフル化を行うため、HTTP認証には所属していない。

認証情報の一時的な保存は、サーバーのセッションデータで行うため、認証解除 (ログアウト) をサーバー側で制御できる。

Cookieヘッダーによる送受信では、CSRFの危険性がある。

• https://h50146.www5.hpe.com/products/software/security/icewall/iwsoftware/report/pdfs/certification.pdf
• https://auth0.com/docs/sessions/cookies#cookie-based-authentication

▼ セッションIDを使用したForm認証の場合

(1)

セッションIDをCookieヘッダーに割り当て、リクエストを送信する。

(2)

最初、ユーザー作成の段階で、クライアントが認証情報をサーバーに送信する。サーバーは、認証情報をDBに保管する。

POST https://example.com/users
---
# ボディ
{"email_address": "foo@gmail.com", "password": "foo"}

(3)

次回の認証時に、再びユーザーが認証情報を送信する。

POST https://example.com/foo-form
---
# ボディ
{"email_address": "foo@gmail.com", "password": "foo"}

(4)

サーバーは、DBの認証情報を照合し、ログインを許可する。サーバーは、セッションIDを作成し、セッションデータに書き込む。

# セッションデータ
{ sessionid: ***** }

(5)

レスポンスのSet-CookieヘッダーにセッションIDを割り当て、クライアントに送信する。

200 OK
---
Set-Cookie: sessionid=<セッションID>

(6)

サーバーは、セッションIDとユーザーIDを紐付けてサーバー内に保管する。

加えて次回のログイン時、クライアントは、リクエストのCookieヘッダーにセッションIDを割り当て、クライアントに送信する。

サーバーは、保存されたセッションIDに紐付くユーザーIDから、ユーザーを特定し、ログインを許可する。

これにより、改めて認証情報を送信せずに、素早くログインできるようになる。

POST https://example.com/foo-form
---
cookie: sessionid=<セッションID>

(7)

認証解除時、サーバーでセッションデータを削除する。

• https://blog.tokumaru.org/2013/02/purpose-and-implementation-of-the-logout-function.html

▼ トークンを使用したForm認証の場合

トークンをCookieヘッダーに割り当て、リクエストを送信する。

この時のトークンの選択肢として、単なるランダムな文字列やJWTがある。

• https://scrapbox.io/fendo181/JWT(JSON_Web_Token)%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B%E3%80%82

▼ Cookieヘッダー値のクライアント保持

再利用のため、Cookieヘッダーに割り当てるための値 (セッションID、トークン) は、ブラウザを通して、ローカルマシンに有効期限に応じた間だけ保持できる。

またはブラウザの設定によって、ブラウザのWebストレージでも保持できる。

Chromeの場合は、Cookieストレージに保持される。

確認方法については、以下のリンクを参考にせよ。

• https://developer.chrome.com/docs/devtools/storage/cookies/
• https://qiita.com/cobachan/items/05fa537a4ffcb189d001

APIキー認証

▼ APIキー認証とは

事前にAPIキーとなる文字列を配布し、認証フェースは行わずに認可フェーズのみでユーザーを照合する認証スキームのこと。

▼ 照合情報の送信方法

自前ヘッダーとして、x-api-keyヘッダーを定義する。これにAPIキーを割り当て、リクエストを送信する。

POST https://example.com/foo
---
x-api-key: <APIキー>

PAT：パーソナルアクセストークンによる認証

▼ PATによる認証

クライアントがパーソナルアクセストークン (個人用アクセストークン) の付与をリクエストし、認証フェースは行わずに認可フェーズのみでユーザーを照合する。

AuthorizationヘッダーにPATを割りあてて、リクエストを送信する。

作成時以降、アクセストークンを確認できなくなるため、クライアントがアクセストークンを管理する必要がある。

POST https://example.com/foo
---
authorization: <パーソナルアクセストークン>

サービス例	トークン名	説明
GitHub	パーソナルアクセストークン	HTTPSプロトコルを使用して、プライベートリポジトリにリクエストを送信するために必要。HTTPSプロトコルを使用する場面として、アプリケーションの拡張機能のGitHub連携、リポジトリのパッケージ化、などがある。 - https://docs.github.com/ja/github/authenticating-to-github/creating-a-personal-access-token

• https://www.contentful.com/help/personal-access-tokens/

03. 複数の認証の組み合わせ

TSV：Two Step Verification (二段階認証)

▼ 二段階認証とは

2個の認証方法を設定し、クライアントを照合する。

一段階目の認証例	二段階目の認証例	説明	備考
IDとパスワード	IDとパスワード	IDとパスワードによる方法の後、別のIDとパスワードによる方法を設定する。
	秘密の質問	IDとパスワードによる方法の後、質問に対してあらかじめ設定した回答による方法を設定する。
	SMS	IDとパスワードによる方法の後、SMS宛に送信した認証コードによる方法を設定する。	異なる要素のため、これは二要素認証でもある。
	指紋	IDとパスワードによる方法の後、指紋の解析結果による方法を設定する。	異なる要素のため、これは二要素認証でもある。

TFA：Two Factor Authorization (二要素認証)

▼ 二要素認証とは

二段階認証のうちで特に、認証時に異なる要素の方法を使用して、段階的にクライアントを照合すること方法のこと。

一要素目の認証例	二要素目の認証例
IDとパスワード (知識)	事前に連携登録されたPC端末のQRコード読込アプリで発行したワンタイムパスワード (所持)
	事前に連携登録されたスマホ端末のQRコード読込アプリで発行したワンタイムパスワード (所持)
	事前登録されたスマホ端末の電話番号のSMSで受信したワンタイムパスワード (所持)
	事前登録されたスマホ端末の電話番号のSMSで受信した認証コード (所持)
	OAuth (所持)
	指紋 (生体)
暗証番号 (知識)	キャッシュカード (所持)

• https://www.quix.jp/quix/two-factor-authentication/

MFA：Multiple Factor Authorization (多要素認証)

▼ 多要素認証とは

記入中...