サーバ屋日記

A systematic test of Google’s OAuth2 PKCE implementation and its implications for different application types. Key Finding : Google’s OAuth2 implementation requires client_secret even when using PKCE for Web Application client types, contrary to RFC 7636 standard expectations. This post documents systematic testing that confirms this behavior and provides architectural guidance for developers. Background: PKCE and Public Clients PKCE (Proof Key for Code Exchange) was introduced in RFC 7636 to address security concerns with public clients—applications that cannot securely store credentials, such as mobile apps and single-page applications (SPAs). The standard OAuth2 flow requires a client_secret , but PKCE provides an alternative mechanism: Generate a random code_verifier Create a code_challenge by hashing the verifier Send the challenge with the authorization request Exchange the authorization code using the verifier According to RFC 7636, this should eliminate the need f...

When implementing OAuth2 authorization and OpenID Connect (OIDC) authentication, developers face numerous configuration choices that significantly impact both security and user experience. While the OAuth2 and OIDC specifications provide guidance, understanding how different combinations of response types and response modes behave in practice requires empirical testing. This post presents a systematic analysis of OAuth2/OIDC flows using Google’s implementation, revealing key insights about token delivery patterns, security implications, and practical recommendations for production deployments. The Challenge: Too Many Options, Too Little Clarity OAuth2 and OpenID Connect (OIDC) offer multiple response types and response modes that serve different purposes: OAuth2 Response Types : - code - Authorization Code Grant (for access tokens) - token - Implicit Grant (direct access tokens) OIDC Response Types : - id_token - Identity tokens for authentication - code token , code id_token ,...