What is the core difference between OAuth 2.0 and OpenID Connect (OIDC)?
OAuth 2.0 answers "what is this client allowed to do?" — it grants delegated access to resources (e.g. "let this app read your calendar") via access tokens, but it does not standardize identity. OIDC adds an authentication layer on top: it issues an ID token (a JWT) that proves who the user is. Rule of thumb: OAuth = authorization (access), OIDC = authentication (identity). "Sign in with Google" is OIDC; "let this app post to your Twitter" is OAuth.
2 / 5
In OAuth 2.0, what is the Authorization Code flow with PKCE and why is PKCE used?
The Authorization Code flow redirects the user to the authorization server, which returns a short-lived code to the client; the client then exchanges that code for tokens at the token endpoint. PKCE (pronounced "pixy") protects public clients (SPAs, mobile apps that cannot keep a secret): the client generates a random code_verifier, sends its hash (code_challenge) at the start, and must present the original verifier at exchange. An attacker who intercepts the code cannot use it without the verifier. PKCE is now recommended for all clients, including confidential ones.
3 / 5
What is the difference between an access token and a refresh token?
An access token is short-lived (minutes to an hour) and accompanies each request to a protected resource. Keeping it short-lived limits the damage if it leaks. A refresh token is long-lived and tightly guarded; the client presents it to the token endpoint to silently obtain a fresh access token when the old one expires, so the user does not have to log in again. Refresh tokens should be stored securely, can be revoked, and are often rotated (a new refresh token is issued each use) to detect theft.
4 / 5
What is a scope in OAuth 2.0?
Scopes express the granularity of access being requested and granted. A client asks for specific scopes (e.g. read:profile, write:repo), the user sees and consents to them on the authorization screen, and the resulting token is limited to exactly those permissions. Scopes enforce the principle of least privilege: an app that only needs to read your email should not receive a token that can also delete it. Resource servers check the token's scopes before honoring a request.
5 / 5
Why should you validate the signature and claims of a JWT ID token rather than just decoding it?
A JWT is signed, not secret: the header and payload are merely base64url-encoded and trivially readable. Trusting a decoded token without verification is a critical vulnerability — an attacker could forge claims like "admin": true. You must: verify the cryptographic signature against the issuer's public key (from the JWKS endpoint), check the iss (issuer) matches your provider, the aud (audience) matches your client, the token is not expired (exp), and reject the alg: none attack. Only then are the claims trustworthy.