2つのAuth -認可と認証-

# はじめに

「Auth = ログインに関わる処理をするもの」という漠然とした理解しかなかったのですが、どうやら複数の意味があるようです。

# ①Authentication（認証）

一般的にイメージされる「ログイン」です。
検索するとこのように出てきます。

> コンピューターやネットワークシステムを[利用](https://dictionary.goo.ne.jp/word/%E5%88%A9%E7%94%A8/)する際に[必要](https://dictionary.goo.ne.jp/word/%E5%BF%85%E8%A6%81/)な本人確認のこと。[通常](https://dictionary.goo.ne.jp/word/%E9%80%9A%E5%B8%B8/)、[ユーザー名](https://dictionary.goo.ne.jp/word/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E5%90%8D/#jn-264759)や[パスワード](https://dictionary.goo.ne.jp/word/%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89/#jn-176411)によってなされる。オーセンティケーション。本人認証。

https://dictionary.goo.ne.jp/word/%E8%AA%8D%E8%A8%BC/


# ②Authorization（認可）

> [適当](https://dictionary.goo.ne.jp/word/%E9%81%A9%E5%BD%93/)と認めて、[許可](https://dictionary.goo.ne.jp/word/%E8%A8%B1%E5%8F%AF/)すること。

https://dictionary.goo.ne.jp/word/%E8%AA%8D%E5%8F%AF/

ITにおいては特に、「アクセス権限を与える・アクセス制御をする」という意味があるようです。

# 両者の違い

一般的な、単語としての違いは以下です。
- 認証：「本人確認」・「アイデンティティ（ID）の検証」
- 認可：「許可を与える」・「アクセス制御」

ただ、比較を通して理解できるものではないようです。

https://dev.classmethod.jp/articles/authentication-and-authorization/#return-note-184783-1

> # 非対称的な並列比較に注意
> 
> さて、以上が認証と認可の切り分けに関する解説です。
> 
> ここまで比較しておいてアレなんですが、認証と認可というのは相互に比較するにあたって「対称性」が無いと思っています。

ということで、比較ではなく具体例を見てみましょう。

個人的に「認可・認証」の理解が進んだと感じた例を紹介します。

# 認可の例

まずは認可の一例を見てみましょう。

認可というのは、「金庫」と「鍵」に喩えられます。
「金庫へのアクセス」を許可する（「鍵を渡す」）・許可しない（鍵を渡さない）ということですね。

この時の登場人物は以下のように考えられます。

- 「金庫の中身の所有者（所有者）」
- 「金庫の中身にアクセスしたい人（利用者）」
- 「鍵を管理する人（管理者）」
- 「金庫」

管理者と所有者は大抵の場合同じですが、違う役割なので分けています。

1. 利用者→管理者 アクセスしたいので、鍵を貸してください
2. 管理者→所有者 鍵を貸していいですか？（はい いいえ）（「はい」の場合は認可）
3. 利用者→金庫 「金庫の中身」をください
4. 金庫→利用者 「金庫の中身」を渡す

# 認証情報へのアクセスを認可する例

先程の例の、「金庫の中身」が認証情報であった場合、
「認証情報へのアクセスを認可する」という例になります。

これは実際に使われている仕組みのようです。
（GithubやGoogleなどのユーザー情報を使用し、別サイトのユーザー登録・ログインをする場合のイメージ。名前をあげたサービスで実際にこの手法が使われているかは不明）

「所有者」を「ユーザー」
「利用者」を「他サイト」
「管理者」を「Google」
「金庫の中身」を「認証情報」

に置き換えてみましょう。

0. ユーザー→他サイト 私の認証情報を使用してください
    
1. 他サイト→Google 鍵を貸してください
2. Google→ユーザー 鍵を貸していいですか？（はい いいえ）（認可）
3. 他サイト→金庫 認証情報をください
4. 金庫→他サイト 認証情報を渡す

5. 他サイト→ユーザー 認証情報を使用し登録・ログイン

# 認証なしの認可・認可なき認証

順番が前後するような気がしますが、引用して紹介します。

https://dev.classmethod.jp/articles/authentication-and-authorization/#return-note-184783-1

> 認証せずに認可することなんてあるのか？
> あります。上の切符の例がそれにあたりますね。
> 
> その他、iptablesの設定で特定のIPアドレスからのリクエストを許可する、なんていうのも認証に基づかない認可です。IPアドレスによって、相手のアイデンティティが確定するとは限りませんね。
> 
> 認証したのに認可しないことなんてあるのか？
> 1つのシステムに閉じて考えている限りは、まず ない と考えて良いでしょう。何のために認証したんだ、ということになります。
> 
> しかし OpenID Connect等、認証の委譲が発生するような分散環境においては複雑な事情がありえます。
> 
> マクロな視点では「Aシステムがユーザの認証を行い、その事実をBシステムに通知した」という状態において、Aシステムは認証をしたが、認可はしていないことになります。
> 
> 一方ミクロな視点では「BシステムはAシステムからユーザを認証したことを通知された。だからBシステムは独自で持つリソースへのアクセスを許すことにした」ということがあるかもしれません。恐らく、あるでしょう。
> 
> しかしそれはミクロの話で、マクロレベルでは認証しただけ。認可したかどうかは 知らん のであります。
> 
> メタファで考えると、マイナンバーカードを使ってレンタルビデオ店の会員権を得る話。マイナンバーカード自体は何も認可をしていません。が、レンタルビデオ店がマイナンバーカードに基いて認可をしています。その状況について、マイナンバーカード発行機関は「知らん」のです。

# 豆知識：略称

Authenticationは"AuthN"
Authorizationは"AuthZ"
とも呼ばれるようです。

# おわりに

以上、認可と認証についてでした。

どっちがどっちだっけ？の覚え方については、以下の記事が参考になりました。

https://qiita.com/kgwryk28/items/dfec493084162f9f9f8c

認証の種類についてはこちらのサイトが参考になります。

https://hypervoice.jp/authentication_authorization

> **Something you know（SYK）**  
> 対象とする人しか知り得ない知識・記憶を元にする認証方法です。パスワードやPIN（Personal Identification Number）がこれに当たります。
> 
> この方法のメリットは実装コストが安価であることです。
> 
> 反面、総当たり攻撃などで破られる可能性があること、設定したパスワード、PINを忘れてしまうといったデメリットもあります。
> 
> **Something you have（SYH）  
> **対象とする人しか持ち得ない所有物を元にする認証方式です。IDカードやICカード・トークンなどがこれに当たります。
> 
> メリットは、ユーザーがパスワードなどを覚えておく必要がなく、簡単に利用できることにありますが、紛失のリスクがあることがデメリットです。
> 
> **Something you are（SYA）**  
> 対象とする人の特徴を元にする認証方式です。指紋認証や顔認証、虹彩認証、静脈認証などの生体認証（バイオメトリック認証、バイオメトリクス認証）がこれに当たります。
> 
> メリットは、SYH同様にパスワードなどを覚えておく必要がなく、本人の身体があれば認証できることですが、体調などによって認証されないことがあること、実装コストが高価であることなどがデメリットとなっています。
> 
> いずれの方法をとった場合でもリスクはゼロにできないため、2つ以上の認証方法を組み合わせる多要素認証（Multi-factor Authentication）を取り入れることが推奨されるようになってきました。
> 
> 例えば、キャッシュカードでお金をおろす時にキャッシュカードを用いて暗証番号を入力します。これは、キャッシュカードという物と暗証番号という知識を用いる2要素での認証となるわけです。