「オレ」が「お前ら」に、認証とか認可とかをしていただく ようなフローで考える。
Authentication（認証≒本人か確認）
wikipediaには、confirming the truthとある。つまり、クライアントに対して、「貴様は間違いなく貴様か？」を確認する。
例えば、「Twitterで、@ndxbn アカウントを作った本人かを確認する（≒クライアントから見たら、ログインする・サインインする）」とか。
「俺」が「お前ら」を信頼していないと成り立たない。世の中の「パスワード漏えいした」とかいうのは、つまり「秘密鍵をばらまいた」というなので、「お前ら」の信頼がなくなる。「お前ら」は、信頼を死守しなければいけない、というプレッシャーに追われるわけだ。
Authorization（認可≒限定的な権威の委譲）
なにかするための 権限（権威、権利…）を与える。権限を与える事ができる人を「権威者」と言うことにする。「権威者」の由来は、Authoritative name serveを権威DNSサーバと訳することに由来する。
例えば、「Twitterで、@ndxbn アカウントでツイートする権限を与える」とか。この権限を与えられるために、権限がほしいクライアントは、自分自身の証明ができるようにするためのものをメッセージングの引数にする。
移譲と委譲の違い
どちらも、「Aが持つ権限・権威・権利を、Bへわたす」部分は同じ。「Bへわたした」後に、「Aに残るか」という点が違う。「移譲」は残らない。「委譲」は残る。
「移譲」は「完全に引き渡すことを目的としている」が、「委譲」は「（一時的に）代わりにやってもらうこと」を目的としている。
OAuth
OAuthって、Authorizationなんだぜ…。
まぁ確かに、「ユーザIDだけをもらう権限」にしてれば、認証っぽく使えるかもしれないけどな。
OAuth 2.0 is not an authentication protocol.
Certification（認証≒本人かを確認する。ただし、お互いに信用してない）
今までのAuthなんとか は、すべて「どっちか片方が信頼・信用されている」ことを前提に成り立っていた。しかし、お互いに信用ならない時だってある。
そういう時は、俺もお前らも信用している「第三者認証機関」を使おうじゃないか。
ちなみに、HTTPSとかでのCertificationは、「お前ら（HTTPクライアント）」の方が、立場は上になる。
お前らの目標は、「"信頼できる"Webコンテンツを取得すること」だから、わざわざWebサーバに対して「オレ氏は信頼できる」フィードバックはしない。むしろうざいからやめろ。（信頼できるかどうかは、アドレスバーの鍵のやつで見れる。）
お前ら（GoogleChromeとか）がオレ（ www.google.coo.jp ）の確認（認証）
認識間違ってたりしたら、ツッコミください。お願いします。