OAuth 2.0
https://gyazo.com/6222b9e6aff3fb33f0a7b60ee9513aeb https://www.youtube.com/watch?v=PKPj_MmLq5Ehttps://gyazo.com/ad0eb1d0a67c75d2ddf19db1a0bbf998
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
概要
OAuth2の登場人物がどのようなプロトコルで認可をしていくのか
OAuth 2.0が何を標準化したものかの抽象的な説明。わかりやすくて最初に読むのにおすすめ
図
学び方
具体的なフロー
認証と認可の違いからOpenID Conect、OAuth 2.0の説明 登場人物
クライアント
データを取得したいアプリケーション
例：自作アプリ
リソースサーバ
取得したいデータのあるアプリケーション
例：Twitter
リソースオーナー
データの所有者
例：Twitterのユーザ
IDトークン
Open ID Provider（発行者）の署名のついたトークン
手順
リソースオーナがクライアント（自作のアプリ）にリクエストを要求する
クライアントは（リソースをいじりたいので）認可サーバに権限委譲処理をリクエストする
リソースオーナは認可サーバに、クライアントに対して権限委譲の認可を与える
「わたしのリソースをつかってもいいよ」
認可サーバはアプリケーションにアクセストークン（鍵）を返す
クライアントはアクセストークン（鍵）を使ってリソースサーバ（Twitter）のリソースを操作する
トークンがあっていればリソースは操作できる
トークンを誰からもらったか、誰が使ったかは関係ない
クライアントがリソースサーバにアクセストークンを渡す際にはRFC6750を使う Authorization: Bearerヘッダ
クライアントがアクセストークンを取得するフローは4種類ある
下に行くほど理想的で複雑
サマリ
Client credentials grant
できる
client id + secret（無期限）からアクセストークン（有効期限あり）を発行
諦め
リソースオーナ（リソースに対する所有権が確認できているユーザ）の認可
Resource owner password credentials grant
できる
リソースオーナのユーザ名/PWからアクセストークンを発行
ユーザはID/Passwordを入力するので、リソースオーナの意思で認可している
Client credentials grantではできていない点が達成
諦め
クライアントはリソースオーナのパスワードを知っている
使いみち
公式クライアント
Implicit grant
できる
リソースオーナが、クライアントにアクセストークンを渡すのを承諾する
諦め
アクセストークンはリソースオーナやブラウザに見えてしまう
callback URLのfragmentに入っている
A URL fragment is a name preceded by a hash mark (#),
サーバサイドにアクセストークンが伝わらない
使いみち
モバイルアプリ
Authorization code grant
理想形
ほぼImplicit grant
違い
コールバック時のリダイレクトではアクセストークンではなくAuthorization codeを返す
Authorization codeをアクセストークンに引き換える
いろいろあることはわかった。結局どれ実装すればいいの？
用語
スコープ
リソースオーナーが委譲に同意した権限の種類
ただし、リソースオーナが権限を持っているかどうかはOAuthは知らないので別途検証が必要
1.0と比べて、SSL/TLSに依存している(ペイロードにsecret keyをかく) モバイルアプリの場合はiOSでjail breakするとクライアント証明書をつかったSSL pinningがdisableできるので、APIが見れる。Clinet secretが載っているのでトークンを取るAPIに対してパスワードを投げたりしてアカウントの生存APIを叩くことができるのでAttackできる
secret keyをembedしないようにする
client keyがOAuth2.0の場合は同じなのでパケットキャプチャすればわかる
1.0は毎回nonceをつくってハッシュ化するので見てもわからない。サーバー側では時刻チェックの実装を入れる。
2をそのまま使うのではなく
キーをコロコロ変えるようにするとか
1のfingerprintやnanceを入れる
iOSのdevice checkを入れる
SDK経由でOSがリクエストをなげる。自分のサーバ経由でAppleにリクエストを投げるとAppleがチェックしてサーバに戻してくれる
本来はアプリごとに2bitだけ安全に読み書きできるしくみだが、2bitをつかわなければよい
クラッカーのリクエストを弾くことができる。Appの中にsecret keyがない。デバイスの中にたぶんsecret keyがある
Androidだとsafety net