The labs on this site need JavaScript to run. The same content is written out below.

Learn › Security › Authentication

OAuth login flow

What is exchanged when you click "Log in with Kakao"

Social login is a procedure in which our service gets permission to access a user's information, with the user's consent, without ever receiving the user's password. Some things travel through the browser, and others are exchanged directly between servers.

Checked against documentation and standards · Checked against the OAuth 2.0 standard (RFC 6749)

Concepts in this lab

OAuth 2.0

An authorization framework that lets a user allow a third-party application limited access to the user's resources without giving it the password. The user logs in at the authorization server (such as Google or Kakao) and gives consent. As a result, the application receives an access token and uses it to access the resources. Social login uses this flow.

Authentication and authorization

Authentication checks who a user is. Authorization decides whether that verified user has permission to use a specific resource or feature. Authentication happens first, and authorization is decided based on its result. In HTTP status codes, a failed authentication corresponds to 401 and a failed authorization corresponds to 403.

Access token and refresh token

An access token is the token that a client presents when it calls an API. Its lifetime is kept short to reduce the damage if it is stolen. A refresh token is the token used to get a new access token when the access token expires. It has a long lifetime and is stored more securely. The server can revoke a refresh token to stop new access tokens from being issued.

Cross-site request forgery (CSRF)

An attack that takes advantage of the fact that a user is logged in: a page made by the attacker causes the user's browser to send an unintended request to the target site. The browser attaches cookies automatically, so the server treats it as a normal request. To block it, require requests to include an unpredictable token issued by the server, or use the SameSite attribute of cookies.

Try these

• Default settings — The whole flow of the authorization code grant.
• The user cancels the consent — An error comes back instead of a code.
• The state value is different — It is not a request that our service started, so it is rejected.
• Intercept and reuse the authorization code — A code can be used only once, and only together with the client secret.

Running with the default settings

1. The user presses the "Log in with Kakao" button on our service (shop.example).
2. Our service redirects the browser to the authorization endpoint of Kakao. It attaches who is making the request (client_id), the address to return to when finished (redirect_uri), the range of information it wants (scope), and a random value that identifies this request (state). Our service remembers the state in the session.
3. The user logs in on the Kakao page and gives consent to share information. The ID and password are entered only at Kakao. Our service cannot see them.
4. Kakao redirects the browser back to the redirect_uri of our service and attaches the authorization code. This code is a very short-lived, single-use code that can be exchanged for a token. It passes through the browser address bar, so it is designed on the assumption that it can be exposed.
5. Our server compares the returned state with the value it remembered in the session. They are the same, so it continues.
6. Our server sends a request directly to the token endpoint of Kakao. Along with the authorization code, it sends the client_secret, which only our server knows. This communication does not go through the browser.
7. Kakao checks the code and the secret and issues an access token. The token is not exposed to the browser and is delivered only to our server. The authorization code is discarded at this moment.
8. Our server calls the user information API of Kakao with the access token. It can receive only the information in the scope that the token allows.
9. The user information has been received. Our service uses the Kakao member number to find our member or to register a new one.
10. Finally, our service does its own login processing. Later requests are authenticated with the session or token of our service, independent of Kakao.

Result of this run

• The authorization code arrives through the browser, while the token is exchanged directly between servers. The structure lets only a value that is useless by itself (the code) travel on the path that is easy to expose.
• OAuth 2.0 is, at its core, a procedure for being delegated permission (authorization). When it is used for login (authentication), the received token is used to look up user information and confirm who the user is, and OpenID Connect standardizes this.

Code

# application.yml (Spring Security OAuth2 client)
spring.security.oauth2.client.registration.kakao:
  client-id: abc123                     # a value that may be public
  client-secret: ********               # a value only the server knows
  authorization-grant-type: authorization_code
  redirect-uri: https://shop.example/login/oauth2/code/kakao
  scope: profile_nickname, account_email

// Spring Security handles the steps below for you

Assumptions of this model

The authorization code grant of OAuth 2.0 is transcribed following the flow in the standard document (RFC 6749). Kakao is only an example, and other providers such as Google and Naver have the same flow. The code and token values are fake values for explanation.

Previous lab: JWT structure and verification · Next lab: Session hijacking and session fixation