そもそも「認証・認可」と「ID管理」ってなんだ？

## はじめに
「認証・認可」と「ID管理」。私たちの実生活においても身近な仕組みだ。だけどその違いを問われると少し難しい。本投稿ではできるだけやさしく説明を試みたい。

※技術的なお話は含みません。（私も含めて）初学者へのイメージの取っ掛かりになれば幸いです。また、Microsoft社の記事を多く引用させていただきましたが、その内容の是非を問うものでもございません。

## 「認証・認可」とは？
まず、「認証」と「認可」はそもそも違う言葉であることを理解したい。

>認証 (authentication、AuthN と表記されることもあります) と認可 (authorization、AuthZ と表記されることもあります) は同じ意味で使われることもよくありますが、この 2 つは互いに関連があるものの、まったく別のものです。認証とは、サインインするユーザーが自称するとおりの人物であることの確認ですが、認可とはそのユーザーが必要としている情報にアクセスするための適切な許可を持っていることの確認です。
>出典：[Microsoft 認証とは？](https://www.microsoft.com/ja-jp/security/business/security-101/what-is-authentication?msockid=13bc13c4f45067af224b0690f5ba66d2)

つまり、`認証とは「相手が本人かどうかを確認すること」`であり、`認可とは「権限をもつかどうかを確認すること」`だ。

### 「認証」「認可」の例
居酒屋の入店プロセスを絵にしてみた。

![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3966253/305d60be-94ac-49dd-a7bd-24abf5e2946c.png)
![2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3966253/6ceecc7f-8943-15c4-9125-cc8e6b13f759.png)
![3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3966253/27682851-886a-6412-3921-e3eb071b4572.png)
![4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3966253/1d5126a1-05ca-5175-c0b1-21ffc4d7f9e5.png)

「認証して認可する」一連のプロセスが暗黙的に行われているが、`本人確認＝認証したうえで、入店資格の有無（年齢）を確認＝認可している`ように、認証と認可はそれぞれに行われている。
逆にいえば、本人確認（認証）できても、年齢が20歳未満だと入店資格はない（認可できない）。このように認証と認可は確かに分離している。

#### 「認証しないで認可」の例
ついでに考えてみる。電車の改札口は切符を通すことで通過できる（認可される）が、そのための本人確認（認証）はない。他人が購入した切符や拾った切符を用いて改札口を通過することができる。このように「認証しないで認可」というケースも世の中にはある。

### 「認証」はどのように行われるか
それでは本人が本人であることを確認するためにはどのような情報が用いられるか。
下記の三要素がある。
- 知識情報：パスワード、暗証番号、秘密の質問など
- 生体情報：指紋、静脈、顔、虹彩など
- 所持情報：カード、デバイス、メール、証明書、乱数表など

このうち２つの要素を利用した認証を「二要素認証」と呼ぶ。
先ほどの居酒屋の例だと、所持（免許証）＋生体（顔）による二要素認証といえようか。

### 「認可」はどのように行われるか
ここは議論があると思うが、本記事の文脈に沿うと以下の２つが適切だろう。
- ロールベースのアクセス制御 (RBAC): ユーザーに静的に割り当てられたロール（役割）に応じて、認可を行う
- 属性ベースのアクセス制御 (ABAC): ユーザーの属性に応じて、ポリシー（条件式）を用いた動的な認可を行う

先ほどの居酒屋の例では後者のABACが当てはまるだろう。「年齢」はその時点から計算されるものであり、その計算結果を用いて認可判定されているためだ。また、ABACの属性には「時」「場所」なども含む。例えば、「客の来店時間が、店の営業時間外の場合、入店できない」というのも時間という属性を用いた動的な制御だ。

RBACは組織内をイメージするとわかりやすい。例えば「部長と一般社員」「本社と支店」「営業部と開発部」など、職位や所属、職務に応じて権限が変わるということだ。当然、それらは複数の権限で構成されており、それらを束ねるのが「ロール」である。

## 「ID管理」とは？
「認証・認可」と並んで「ID管理」という言葉をよく目にする。IDとは狭義にはリソースを一意に識別するための識別子であるが、広義にはその属性情報を含む。組織のユーザーIDであれば氏名、認証情報、職位、所属、職務、入社日、退職日などだ。それらを管理することが「ID管理」だ。

### ID管理と認証
では、ID管理と認証はどのように連動するか。
>ID 管理データベースに格納される情報の種類の例としては、従業員の氏名、役職、マネージャー、直属の部下、携帯電話番号、個人メール アドレスがあります。ある人物のログイン情報 (たとえばユーザー名とパスワード) をデータベース内のその人の ID と照合することを、認証といいます。
>出典：[Microsoft ID アクセス管理 (IAM) とは?](https://www.microsoft.com/ja-jp/security/business/security-101/what-is-identity-access-management-iam?msockid=13bc13c4f45067af224b0690f5ba66d2)

IDの属性情報には認証情報も含まれ、その管理も含めてID管理と言うことだ。

### ID管理と認可
ID管理と認可はどうか。
>ほとんどの組織では、リソースとデータへのさまざまなレベルのアクセスが許可されており、このレベルは役職、在職期間、セキュリティ クリアランス、プロジェクトなどの要因によって決定されます。
>ユーザーの ID が認証された後に正しいレベルのアクセスを許可することを、認可といいます。
>出典：[Microsoft ID アクセス管理 (IAM) とは?](https://www.microsoft.com/ja-jp/security/business/security-101/what-is-identity-access-management-iam?msockid=13bc13c4f45067af224b0690f5ba66d2)

認可の要因として役職や在職期間などが挙げられており、それらはまさにIDの属性情報を用いるものだ。

## まとめ
私見だが、「認証は本人確認」「認可は権限確認であったり権限そのものであったり」「それらに用いる情報はID管理システム内にある（こともある）」くらいでまずは良いと思っている。というのも、これらはどの視点で語るか、システムの構成・制約、話の文脈、話者によって揺れる感があり。ある程度遊びを持たせて構えておくことが、理解の促進と余裕を生むと感じるのだ。（技術的な理解を放棄してよい、ということでは決してない）