トークン
普通にWebアプリ設計してて、アクセストークンの定義したけど、これ必要なんだっけ？ ってなったので
そもそもOAuth使わない文脈では登場しない概念なので普通にWebアプリ設計していてこの話が出るのは、大変にポカをやらかしてる。
用途：Webサービス同士が個人情報をやり取りする際の、許可手形
あるサービスAで保存してる情報を、別のサービスBで使う場合、無許可で行ってはいけない（当然）
サービスBがサービスAの情報を使うことを、ユーザーが許可した事を証明する文字列が、アクセストークン
例えば・・・
Slack側で、あるURLを叩くと特定のChannelに投稿するよう設定する
この時、Slackはアクセストークンを発行する
Github側で、PRを出したらSlackのURLを叩くよう設定する
この時、Slackが発行したアクセストークンをGithubに設定する
Githubは、PRが出た時、アクセストークンを付与してSlackへ通知（URLを叩く）する。
Slackは、受信したアクセストークンから、どのChannelへ投稿すればよいか判断する
実際はOAuthを使ってもうちょっと自動化する。
GithubでPRが出たらSlackへ連携するよう設定する
GithubからSlackへリダイレクトし、ユーザーにSlackへの投稿許可を求める
ユーザーが投稿を許可すると、Slackはアクセストークンを発行して、Githubへリダイレクトする
Githubがアクセストークンを受け取り、自身のDBへ登録
PRが出た時、Githubはアクセストークンを付与してSlackへ通知
アクセストークンと合わせて良く話に出てくる概念
アクセストークンの有効期限が無期限（あるいは非常に長い）と、パケットスニッファ（盗聴）された時にブロックできなくて良くない。 そこで、アクセストークンに有効期限を設けるが、有効期限が切れた場合、再度ユーザーに許可を求める運用になる。
アクセストークンの有効期限は、短ければセキュリティに強くなるため、なるべく短く設定したい。しかし、それだと再認可の手続きが頻発して利便性を損ねる（一般的には30日位らしい）
アクセストークンは、サービス間の通信の度にやり取りされるため、盗聴の機会が非常に多い。この、「盗聴の機会」に着目してセキュリティを向上させるのがリフレッシュトークン
アクセストークンが期限切れになった時、リフレッシュトークンを用いて再度アクセストークン（とリフレッシュトークン）を再発行してもらう。
リフレッシュトークンは有効期限を（アクセストークンより）長く設定するが、利用するのはアクセストークンが有効期限切れになった時だけなので、盗聴機会が非常に少なくなるため、アクセストークンだけを使用するよりもセキュリティが向上する。
上記の、アクセストークンを用いた認証の仕組みを、OAuthに関係のない所で（セッションIDのような）使い方をしても良いように仕様化したものがBearerトークン
トークンのやり取りの仕方や用途、と言うよりも、HTTP通信においてどんなトークン（使ってよい文字とか）をどのように設定するか（Authorizationヘッダに書き込め、など）が話の中心で、ちょっと視点が異なる