Authenticating the user involves obtaining an ID token and validating it. ID tokens are a standardized feature of OpenID Connect designed for use in sharing identity assertions on the Internet.
After obtaining user information from the ID token, you should query your app's user database. If the user already exists in your database, you should start an application session for that user if all login requirements are met by the GoogleAPI response.
ユーザーのログインまたは端末でのログインが成功すると、Firebase で独自の ID トークンが作成され、この ID トークンでユーザーまたは端末を特定し、Firebase Realtime Database や Cloud Storage などのリソースへのアクセスを許可します。この ID トークンは、カスタム バックエンド サーバーのユーザーまたは端末を識別するために再利用できます。クライアントから ID トークンを取得するには、ユーザーがログインしたことを確認してから、ログインしたユーザーから ID トークンを取得します。
However, beyond what is required for JWT, ID Tokens also contain claims asserted about the authenticated user, which are pre-defined by the OpenID Connect (OIDC) protocol, and are thus known as standard OIDC claims. Some standard OIDC claims include:
という面から、"OIDC を調べて nonce の検証したら state の検証いらないって気づいちゃった" 派が一定数出てくるでしょう。
state と同じ、フロントチャンネルで AuthZ(AuthN) Response に含まれる ID Token の nonce を検証するならば state は不要でしょう 。
ただし、フロントチャンネルでは ID Token を扱わず、バックチャンネルでの Access Token Response までやって ID Token の検証をするのであれば、"もっと早い段階でチェックできるものはする(stateのゆるい検証と併用する)" という考え方もありかなと思います。
code_challenge, code_verifier by PKCE
PKCE は "Proof Key for Code Exchange by OAuth Public Clients" です。
Secret を安全に管理できない Public Client(ネイティブアプリやブラウザベースアプリなど)は Implicit Grant ではなく AuthZ Code Grant + PKCE 使え！
個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。
なのでそれはおいといて、この話題を扱う記事は
クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / SessionStorage)
JWTに親でも●されたかのような JWT as a Session な記事の批判は大体がここまで紹介したあたりの話かと思いますが、ここまでの話は JWT が注目される前から存在するものであり、JavaScript での操作の需要が増えて注目されてはいるものの、「枯れた実装」ならぬ「枯れた設計」でしょう。
In addition, WebAuthn can make it possible to support login using your device as a “single-factor” security key with biometric authentication instead of a password. Although we’re not ready to announce further plans, we’ll continue to pursue ways to make secure authentication as easy as possible for everyone on GitHub.
3D Secure 1.0ではXYZのTransaction Request相当のリクエストでカード情報などを送り、ワンタイムパスワードの確認を行うURLにアクセスします。
3D Secure 2.0ではより情報を増やし、リスクベースの判定をしたりします。
Transactionalと言う名前からも、この辺りは共通する部分だったり参考にできる部分はありそうですね。
