OAuth2 social login with your own JWT

WHAT THIS TESTS Whether you can describe the OAuth2 authorization code flow concretely and explain the boundary between external identity and your application's own session, including security steps.

A GOOD ANSWER COVERS The high-level flow uses the authorization code grant. Endpoint one, a login initiation route such as GET /auth/google/login, builds the provider's authorization URL with your client_id, the registered redirect_uri, requested scopes (for example email and profile), and a random state value stored server-side or signed for CSRF protection, then redirects the browser there. The user authenticates and consents at the provider. Endpoint two, the callback such as GET /auth/google/callback, receives a short-lived authorization code and the state. You verify state matches, then make a server-to-server POST exchanging the code plus your client_secret for the provider's access token, never exposing the secret to the browser. You call the provider's userinfo or user API with that token to retrieve a stable user id and email. You then upsert a local user record keyed by the provider id, and finally mint your own application JWT (and refresh token) so all later requests use your auth, independent of the provider. Libraries like Authlib wrap much of this. The crucial point is that the provider proves identity once; your own JWT is your session of record.

COMMON WRONG ANSWERS Skipping the state parameter, leaving the flow open to CSRF. Exchanging the code or holding client_secret in the frontend. Using the provider's access token directly as the user's session token instead of issuing your own. Forgetting to create or link a local user record.

LIKELY FOLLOW-UPS What does PKCE add and when is it needed? Why is state important? How do you link an OAuth identity to an existing email account?

ONE CONCRETE EXAMPLE User hits /auth/github/login, is redirected to GitHub with state=abc. GitHub redirects back to /auth/github/callback?code=xyz&state=abc; the backend verifies state, POSTs code plus client_secret to GitHub's token endpoint, gets an access token, calls /user to read the GitHub id and email, upserts a local user, and returns your own signed JWT the SPA uses thereafter.