サーバ屋日記

Google OAuth2 and PKCE: Understanding Client Secret Requirements 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 ...

OAuth2 Flow Testing: A Comprehensive Analysis of Response Types and Modes When implementing OAuth2 authentication, developers face numerous configuration choices that significantly impact both security and user experience. While the OAuth2 specification provides 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 flows using Google’s OAuth2 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 offers multiple response types ( code , token , id_token , and combinations) and response modes ( query , fragment , form_post ). This creates a matrix of possibilities: Response Types : 7 different combinations Response Modes : 3 different delivery methods Scopes : Various combinations affecting token ...