← Developer home

Getting started with DOEH IdentityDOEH Identity ဖြင့် စတင်ခြင်း

DOEH Identity lets your app act for a customer — with their consent, without ever seeing their credentials. The customer signs in on a DOEH-hosted page (OTP), approves exactly the access your app asked for, and your app receives tokens scoped to that grant. This is OAuth 2.1 with PKCE; if you have used "Sign in with X", you know the shape.

DOEH Identity သည် သင့် app ကို customer ကိုယ်စား ဆောင်ရွက်ခွင့်ပေးသည် — customer ၏ သဘောတူညီချက်ဖြင့်၊ သူတို့၏ password/OTP ကို သင့် app က ဘယ်တော့မှ မမြင်ရဘဲ။ customer သည် DOEH-hosted စာမျက်နှာတွင် sign in ဝင်ပြီး သင့် app တောင်းသော access ကိုသာ အတည်ပြုသည်။ သင့် app သည် ထို grant အတိုင်း scope သတ်မှတ်ထားသော token များ ရရှိသည်။ ဤသည်မှာ PKCE ပါသော OAuth 2.1 ဖြစ်သည်။

1 · Register a client

၁ · Client မှတ်ပုံတင်ပါ

A consumer client is a publishable key (pk_test_… — identifies your app and shop, grants nothing alone) plus a client_id with pre-registered redirect URIs. An unregistered redirect_uri is refused with 400 and no redirect. Self-serve registration is coming to the portal; today, request sandbox credentials through your DOEH contact.

Consumer client ဆိုသည်မှာ publishable key (pk_test_… — သင့် app နှင့် ဆိုင်ကို identify လုပ်သည်၊ တစ်ခုတည်းနှင့် ဘာမှ ခွင့်မပြု) နှင့် ကြိုတင် မှတ်ပုံတင်ထားသော redirect URI များ ပါသည့် client_id ဖြစ်သည်။ မှတ်ပုံမတင်ထားသော redirect_uri ကို 400 ဖြင့် ငြင်းပယ်ပြီး redirect မလုပ်ပါ။ ယနေ့အတွက် sandbox credential များကို သင့် DOEH ဆက်သွယ်ရေးလမ်းကြောင်းမှတစ်ဆင့် တောင်းဆိုပါ။

2 · Sign the customer in (OAuth 2.1 + PKCE)

၂ · Customer ကို sign in ဝင်ခိုင်းပါ (OAuth 2.1 + PKCE)

Discover the endpoints (never hardcode them):

Endpoint များကို discovery ဖြင့် ရှာပါ (hardcode မလုပ်ပါနှင့်):

GET https://auth-sandbox.doehpos.com/.well-known/openid-configuration

Generate a code_verifier (random, 43–128 chars) and its code_challenge (base64url of its SHA-256 — method S256, the only one accepted), then open the system browser at:

code_verifier (random, စာလုံး ၄၃–၁၂၈) နှင့် ၎င်း၏ code_challenge (SHA-256 ၏ base64url — method S256 တစ်ခုတည်းသာ လက်ခံ) ကို ဖန်တီးပြီး system browser ကို ဖွင့်ပါ:

{authorization_endpoint}?response_type=code
  &client_id={client_id}
  &redirect_uri={registered_uri}
  &code_challenge={challenge}&code_challenge_method=S256
  &scope=loyalty:read&state={random}

DOEH shows hosted login (OTP) and the consent screen. Your redirect URI receives code (valid 60 seconds, single attempt), state (verify it matches) and iss (verify it is the issuer). Exchange it:

DOEH က hosted login (OTP) နှင့် consent စာမျက်နှာ ပြသည်။ သင့် redirect URI သို့ code (၆၀ စက္ကန့်၊ တစ်ကြိမ်သာ)၊ state (တူညီမှု စစ်ပါ) နှင့် iss (issuer ဟုတ်မဟုတ် စစ်ပါ) ရောက်လာမည်။ ထို့နောက် လဲလှယ်ပါ:

POST {token_endpoint}
grant_type=authorization_code&code={code}
&code_verifier={verifier}&redirect_uri={registered_uri}&client_id={client_id}

→ { "access_token": "dat_…", "token_type": "Bearer",
    "expires_in": 600, "refresh_token": "drt_…", "scope": "loyalty:read" }

3 · Call the Consumer API

၃ · Consumer API ကို ခေါ်ပါ

GET https://sandbox-api.doehpos.com/v1/mobile/loyalty/balance
X-Publishable-Key: pk_test_…
Authorization: Bearer dat_…

Authorization is decided per request from live consent: if the customer withdraws a permission, the same token gets 404 immediately — an ungranted resource is invisible, not "forbidden" (see the error reference).

Request တစ်ခုချင်းစီအတွက် လက်ရှိ consent မှ ဆုံးဖြတ်သည် — customer က ခွင့်ပြုချက် ရုပ်သိမ်းလျှင် တူညီသော token သည် ချက်ချင်း 404 ရမည်။ ခွင့်မပြုထားသော resource သည် မမြင်ရ ဖြစ်သည်၊ "forbidden" မဟုတ်ပါ (error အကိုးအကား ကြည့်ပါ)။

4 · Refresh tokens

၄ · Token များ refresh လုပ်ပါ

POST {token_endpoint}
grant_type=refresh_token&refresh_token=drt_…&client_id={client_id}

Every rotation returns a new refresh token and retires the old one. Reusing a retired refresh token revokes the whole family (it reads as theft) — so serialize refreshes: one at a time, share the result.

Rotation တစ်ကြိမ်စီတိုင်း refresh token အသစ် ပြန်ပေးပြီး အဟောင်းကို ရပ်ဆိုင်းသည်။ ရပ်ဆိုင်းပြီးသား refresh token ကို ပြန်သုံးလျှင် family တစ်ခုလုံး revoke ဖြစ်မည် (ခိုးယူမှုဟု ဖတ်သည်) — ထို့ကြောင့် refresh များကို တစ်ကြိမ်တစ်ခုသာ လုပ်ပြီး ရလဒ်ကို မျှဝေပါ။

5 · DPoP — coming for native apps

၅ · DPoP — native app များအတွက် လာမည်

Native clients will bind their tokens to a hardware-backed P-256 key (ES256): the key's thumbprint rides /authorize, and every request then carries a signed, single-use proof — a stolen token string alone becomes worthless. The server support is live; the contract ships with the native SDK. Browser and server integrations keep using bearer tokens as above.

Native client များသည် token များကို hardware-backed P-256 key (ES256) နှင့် ချည်နှောင်မည် — key ၏ thumbprint သည် /authorize နှင့်အတူ သွားပြီး request တိုင်းတွင် လက်မှတ်ထိုးထားသော တစ်ကြိမ်သုံး proof ပါမည်။ ခိုးယူထားသော token string တစ်ခုတည်းသည် အသုံးမဝင်တော့ပါ။ server ဘက် အထောက်အပံ့ လက်ရှိ ရှိပြီးဖြစ်သည်။