SSO test cases, including the one that hands over the account

The unverified email is the defect worth building this set around. A provider returns an email claim, that claim matches an existing account, and the implementation links them and issues a session. If the provider did not verify the address, anyone who can create an account at that provider using a victim address now owns the victim account in your application. The rule is simple and rarely tested: never link automatically on an unverified identifier, and match returning users on the immutable subject identifier rather than on the email, because email addresses change and are not unique across providers.

The callback parameters carry the security of the whole flow and both are commonly unchecked. The state value is the cross site request forgery defence, and without it an attacker can complete their own authorisation and have the resulting identity attached to a victim browser session. The authorisation code is single use, and a successful replay should not merely fail but should invalidate the tokens already issued for that exchange. Redirect validation belongs in the same group and needs an exact allow list, because prefix or substring matching is defeated by an attacker controlled subdomain.

Token validation fails in ways that look like success. An implementation that reads the algorithm from the token header rather than pinning it will accept a token signed with none. One that checks the signature but not the issuer and audience will accept a valid token minted for a different application. And a generous clock skew tolerance makes expiry decorative. Each of these is a single case with a crafted token, and each one is the difference between authentication and the appearance of it.

Finally, the lifecycle is where enterprise deployments actually get burned. Group membership changes at the provider need to reach the application within a documented window rather than at the next natural session expiry, and a user disabled at the provider must not be able to continue on an existing session or refresh token. The related cases are unglamorous and matter: rotate the session identifier after authentication to prevent fixation, require step up authentication before a destructive action, and make sign out invalidate on the server rather than merely clearing a cookie in one browser.