놀아 Account
한국어KO EnglishEN Tiếng ViệtVI
Contents

Integrate in 5 minutes

Eight steps from registering your service to your first successful sign-in. Start here.

This is the whole process of adding 놀아 Account sign-in. Follow the steps in order from the top. If you get stuck, check the Error code dictionary first.

Know this first — PKCE is required, not optional. 놀아 Account rejects authorization requests that have no code_challenge (pkce_required). Only S256 is accepted. Step 5 below is where you prepare it.
STEP 1

Register your service

In My account ▸ Register a service, enter your service name and service URL. The service URL must be a domain that is actually in operation.

STEP 2

Verify domain ownership

Choose one of the two.

MethodWhat to do
HTML fileDownload the verification file from My account and upload it, unchanged, to https://your-domain.com/nolaa-member-verification.html.
DNS TXTRegister the issued token value as a TXT record on _nolaa-member-verification.your-domain.com.
DNS changes take time to propagate. If it doesn't work right away, press “Verify” again a few minutes later.
STEP 3

Register the callback URL

This is where the user returns after signing in. Example: https://your-domain.com/oauth/callback

The callback URL must be on the same host as the service URL, and must be a sub-path of the service URL. The redirect_uri in your authorization request must also match the value registered here character for character. Even a single trailing slash makes the request fail with invalid_redirect_uri.
STEP 4

Get your client_id and client_secret

Once domain verification and callback registration are both done, the two values appear on your service card in My account.

Use client_secret on your server only. If it goes into code that reaches the browser (front-end JS, a mobile app bundle), anyone can pull it out. Always do the token exchange on your server.
Reissuing invalidates the previous secret immediately. When you press “Reissue” in My account, the new secret is shown on screen exactly once, and from that moment token requests made with the old secret are rejected with invalid_client. If your service is already live, get ready to switch your server configuration to the new value before you reissue.
STEP 5

Create the PKCE values

Before you send the user away, create a code_verifier on your server and store it in the session. code_challenge is the SHA-256 hash of it, encoded as base64url.

// PHP
$verifier  = rtrim(strtr(base64_encode(random_bytes(32)), '+/', '-_'), '=');
$challenge = rtrim(strtr(base64_encode(hash('sha256', $verifier, true)), '+/', '-_'), '=');
$state     = bin2hex(random_bytes(16));
$_SESSION['nolaa_verifier'] = $verifier;
$_SESSION['nolaa_state']    = $state;
STEP 6

Add the sign-in button

You can copy the button code and icon from Build the sign-in button. The button's link URL has the form below.

https://account.nola.kr/oauth/authorize
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=YOUR_REDIRECT_URI
  &scope=profile.basic%20profile.avatar
  &state=RANDOM_STATE
  &code_challenge=CODE_CHALLENGE
  &code_challenge_method=S256

state is required too. If it is missing, the request is rejected with invalid_request.

STEP 7

Exchange the code for tokens in the callback

When the user consents, they come back to your callback URL with code and state appended. First check that state matches the value you stored, then exchange the tokens.

curl -X POST https://account.nola.kr/oauth/token \
  -d "grant_type=authorization_code" \
  -d "code=RECEIVED_CODE" \
  -d "redirect_uri=YOUR_REDIRECT_URI" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "code_verifier=SAVED_VERIFIER"

An authorization code is valid for 10 minutes and can be used only once.

STEP 8

Get the user info

curl https://account.nola.kr/oauth/userinfo \
  -H "Authorization: Bearer ACCESS_TOKEN"

The fields you get back, and what each scope returns, are covered in the Scope reference.

sub is different for each service (pairwise). The same user gets a different sub in a different service. Use sub as the key that identifies the user, but don't mistake it for a value you can match against other services.

Next