t3-oss/create-t3-turbo: Clean and simple starter repo using the T3 Stack along with Expo React Native github.com/t3-oss/cr…
Allusionist 33: Please — The Allusionist www.theallusionist.org/allusioni…
AWS re:Invent 2024 - SaaS meets cell-based architecture: A natural multi-tenant fit (SAS315) - YouTube www.youtube.com/watch
OAuth2、いままでよくわかってなかったけど、自分で使ってみてようやくちゃんと理解したわ
allowing the authorization server to verify that the app requesting the access token is the same one that initiated the OAuth flow
やっぱりこれだけがPKCEの本質なのであって、リクエストをinitiateした主体がclient_idの所有者であるということはなにも保証しない、はず。
OAuth2/PKCEの要点を一言で言うと、リダイレクトで返される情報(Code)はセキュアでないので、どうやってセキュリティーを担保するか、ということだな。
PKCEの本質は、コード(トークンの発行券)をいかに保護するかって話で、schemeのハイジャック云々はあまり関係ない気がするなあ。けっきょくウェブだったとしても、SPAとかではPKCE必要なわけだし。
PKCE: What and Why? - Dropbox
PKCEについてよく理解できない点がある。PCKEの場合、client_secret を完全に省略することができるってことだけども、PKCEではたしかにコードを要求した主体と、トークンを取得しようとしている主体が同じであることは証明できるけども、けっきょくリダイレクト先のスキームを所有していないという点はなにも解決されておらず、クライアントの真正性についてはなにも証明されていないような? Aというアプリケーションのclient_idを使って、Bというまったく無関係なアプリがOAuthのフローを開始することができるような気がするけど、それはとくに問題にはならないのかな。