OAuth認証
参考
OAuthは本来、認可のためのプロトコル
普通の使い方
これとは別に、OAuthを用いた認証が存在する
言葉の誤りではなく本当に認証をしているmrsekut.icon
流れ
access tokenを付与してrequest
PRは、access tokenを見て、userを特定
PRは、そのuserに関するprofile情報をresponse
こういうAPIのことを 『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』.iconでは「プロフィールAPI」と呼んでいる 一般的な名称ではないと思うmrsekut.icon
便利なのでこの単語使うかmrsekut.icon
⑥access tokenをPRに送る
⑦PRがユーザー情報をclientに返す
これによって、clientは「userがログインした」と見なす
①~⑦の間は、userはclientにログインしていない
OAuth認可の場合は、①が始まる前にすでにログインしている前提
流れの中で2箇所「認証」があるので紛らわしい
Auth Serverによる認証
userが、resource ownerであることを確認するために行う
これはOAuth認可の中にも存在する手順mrsekut.icon
「OAuth認証」が指す認証
userをclientにloginさせるための認証
権限委譲にOAuthを使っているかどうかは実際はあまり関係ない
『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』.iconでは「プロフィール認証」と呼んだほうが適切じゃない?と書いてる
たしかにmrsekut.icon
脆弱性
OAuthは認証のためのプロトコルではない
OAuth認証は、OAuthの仕様に沿っていたとしても脆弱性がありうる
clientはaccess tokenの中身を読めない
client1はそれをチェックできない
PRは、access tokenが来たら、相手が誰であろうと許可する
切符なので
相手がclient2なのかclient1なのかは知らん
clientと全く同じ立場のclient2を作れば、同等のaccess tokenを取得できる
手順
client2を作る
client2にuserをログインさせる
access tokenが得られる
それを使って、PRにreqを投げれば、client1にログインが可能
『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』.icon 3.3
認可コードがあるから
『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』.icon p.27 コラム
facebookの回避法
『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』.icon p.31
どれぐらい一般的なものなのか?
脆弱性を回避するためには特殊な実装が必要?
だから、素直にOIDC使ったほうが楽だよみたいなノリはある?
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる