oidc

oauth

認可サーバー→事前に申請してクライアントid、クライアントシークレットを発行。アプリはそれを持っておく

ユーザーが連携要求→クライアントidをつけて認可サーバーにリダイレクト
ユーザーは認可サーバーでid/passなど入力して承認
アプリに認可コードが届く
認可コードとユーザーを紐づける？？←これは違う

認可コードを認可サーバーに渡してアクセストークンをもらう
アクセストークンでリソースサーバーにアクセスして必要なものをもらう

ここからoidc
認可コードを認可サーバーに渡すと、アクセストークン＆リフレッシュトークンに加え、idトークンがもらえる。厳密にはパターンによって違い、idトークンは絶対もらえる。
jwt形式になっていて、この中にユニークなidが入っている。

ディスカバリーエンドポイント、連携初めにプロバイダから情報もらうやつ

jwk setアンドポイント、idトークン検証のための公開鍵がわかる

ユーザーidなどはstateパラメーターにjsonをbase64エンコードして追加する感じ
これで後から連携ができる

連携解除はrevokeエンドポイントにアクセストークンを渡す

認可トークンで、idトークン、アクセストークン、リフレッシュトークンをもらう？
idトークンはjwt形式で、デコードしたsubがプロバイダのユーザーid

まあ、あんまり使わなそうで
アクセス、リフレッシュトークンだけアプリで保持する感じかなあ

古いoauth。アクセストークンを抜かれる可能性があるのでキケン

oauth2.0 認可だけしかしない
oidc auth2.0の拡張で、認証もする

認可サーバーからもらうトークンなどの検証について

sso