#WebHook
GitHubなどPostする仕組み
#OAuth2.0
認可サーバー（Google)で認証情報によりアクセストークンを発行。（このアプリのアクセスを許可しますか？YES）
アクセストークン付きでAPIをコールし、アクセストークンを検証
https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be
サービス間で認可情報を受け渡せると，あるサービスがユーザの認可のもとで別のサービスの管理する情報の取得／追加／更新／削除などを行えるようになる
OAuthに対応したサービスでは，ユーザが外部サービスにパスワードを教えることなく，認可情報の委譲が可能なため、Basic認証と比べて柔軟かつセキュアな運用が可能
例）
コンシューマがアプリ/ssoにアクセス
アプリが認可へリダイレクト（state付き）、このアプリにemailを渡してもいいですか？YES
Googleがアプリ/callbackへリダイレクト
アプリがstate検証後、トークンから共通鍵でJSONへ復元しemailを取得し、DB認証
state:CSRFを防ぐ
Webアプリの場合、client_secretをもてる。
Googleの場合は、共通鍵方式、client_idとclient_secretがサービスに必要
内包型とは、認可サーバーへの問い合わせが不要。
https://qiita.com/TakahikoKawasaki/items/970548727761f9e02bcd
＃JWT
<ヘッダー>.<ペイロード>.<署名>
BASE64でJSONからトークンへ変換
{
"typ": "JWT",
"alg": "HS256"
}
{
"admin": true,
"name": "John Doe",
"sub": "1234567890"
}
署名パートは、エンコード済みヘッダー、ピリオド（"."）、エンコード済みペイロードを連結したものを入力値として"alg"の署名アルゴリズムで署名し、Base64urlエンコードすることにより作成されます。
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
こちらの文字列をヘッダーで指定されたアルゴリズムで署名検証することにより、ID Tokenの正当性を評価できます。https://techblog.yahoo.co.jp/advent-calendar-2017/jwt/