Ugrás a tartalomra
Sursa Developers

POST/oauth/token

OAuth 2.0-token kiadása

oauth_token

Az OAuth 2.0 tokenkiadási végpontja (RFC 6749, 3.2. szakasz). grant_type: az authorization_code egy egyszer használható kódot cserél tokenpárra, és megköveteli a code_verifier értéket (PKCE S256); a refresh_token egy frissítési tokenért új párt ad ki, és érvényteleníti az előző frissítési tokent (megújítás), egy érvénytelenített token újbóli használata pedig a teljes láncot visszavonja; a client_credentials a szervezet nevében ad ki tokent, csak confidential alkalmazásnak, frissítési token nélkül. A confidential kliens az Authorization: Basic fejléccel vagy a client_id és a client_secret mezővel hitelesít; a nyilvános kliens csak a client_id értéket küldi. A hozzáférési token 1 óráig, a frissítési token 90 napig érvényes. A válaszok és a hibák az RFC 6749 5. szakaszát követik, Cache-Control: no-store fejléccel. Az 1.62.0 verzióban jelent meg.

Hitelesítés

Nincs szükség hitelesítő adatokra.

Kéréstörzs

application/x-www-form-urlencoded

Objektum: OAuthTokenRequest

  • grant_typestringkötelező

    Megengedett értékek: authorization_coderefresh_tokenclient_credentials

  • codestring

    Engedélyezési kód (authorization_code).

  • redirect_uristring

    Ugyanaz az átirányítási URI, mint az engedélyezési kérésben (authorization_code).

  • code_verifierstring

    Az eredeti PKCE-érték, 43–128 karakter (authorization_code).

  • refresh_tokenstring

    Frissítési token (refresh_token).

  • scopestring

    Szóközzel elválasztott hatókörök, csak szűkítésre (refresh_token, client_credentials).

  • client_idstring

    Az alkalmazás azonosítója, ha a titkos kulcs nem az Authorization: Basic fejlécben érkezik.

  • client_secretstring

    Egy confidential alkalmazás titkos ügyfélkulcsa, ha nem az Authorization: Basic fejlécben érkezik.

Válaszok

200A tokenek kiadása megtörtént.

Válaszfejlécek

  • RateLimit-Policy

    Az érvényben lévő korlátok az IETF draft-ietf-httpapi-ratelimit-headers tervezetének formátumában: vesszővel elválasztott "<name>";q=<quota>;w=<window in seconds> elemek. A key az API-kulcs kérésgyakorisága (a kvóta a csúcskeret, az időablak a teljes visszatöltődés ideje; munkamenetnél user, hitelesítő adatok nélkül ip); a minute, a day és a month a szervezetnek az UTC szerinti naptári percre, napra és hónapra szóló kvótája.

  • RateLimit

    Mennyi maradt a RateLimit-Policy egyes korlátaiból: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    A RateLimit-Policy legszigorúbb elemének korlátja (amelyből a legkevesebb kérés maradt).

  • X-RateLimit-Remaining

    A legszigorúbb korlát szerint még hátralévő kérések száma.

  • X-RateLimit-Reset

    A legszigorúbb korlát visszaállásáig hátralévő másodpercek.

application/json

Objektum: OAuthTokenResponse

  • access_tokenstringkötelező

    Hozzáférési token (kbat_…) az Authorization: Bearer fejléchez.

  • token_typestringkötelező

    Megengedett értékek: Bearer

  • expires_inintegerkötelező

    A hozzáférési token élettartama másodpercben.

  • refresh_tokenstring

    Frissítési token (kbrt_…); client credentials esetén hiányzik.

  • scopestringkötelező

    A token szóközzel elválasztott hatókörei.

400Az RFC 6749 5.2. szakasza szerinti hiba.

Válaszfejlécek

  • RateLimit-Policy

    Az érvényben lévő korlátok az IETF draft-ietf-httpapi-ratelimit-headers tervezetének formátumában: vesszővel elválasztott "<name>";q=<quota>;w=<window in seconds> elemek. A key az API-kulcs kérésgyakorisága (a kvóta a csúcskeret, az időablak a teljes visszatöltődés ideje; munkamenetnél user, hitelesítő adatok nélkül ip); a minute, a day és a month a szervezetnek az UTC szerinti naptári percre, napra és hónapra szóló kvótája.

  • RateLimit

    Mennyi maradt a RateLimit-Policy egyes korlátaiból: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    A RateLimit-Policy legszigorúbb elemének korlátja (amelyből a legkevesebb kérés maradt).

  • X-RateLimit-Remaining

    A legszigorúbb korlát szerint még hátralévő kérések száma.

  • X-RateLimit-Reset

    A legszigorúbb korlát visszaállásáig hátralévő másodpercek.

application/json

Objektum: OAuthErrorResponse

401Érvénytelen ügyfél-hitelesítő adatok (`invalid_client`).

Válaszfejlécek

  • RateLimit-Policy

    Az érvényben lévő korlátok az IETF draft-ietf-httpapi-ratelimit-headers tervezetének formátumában: vesszővel elválasztott "<name>";q=<quota>;w=<window in seconds> elemek. A key az API-kulcs kérésgyakorisága (a kvóta a csúcskeret, az időablak a teljes visszatöltődés ideje; munkamenetnél user, hitelesítő adatok nélkül ip); a minute, a day és a month a szervezetnek az UTC szerinti naptári percre, napra és hónapra szóló kvótája.

  • RateLimit

    Mennyi maradt a RateLimit-Policy egyes korlátaiból: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    A RateLimit-Policy legszigorúbb elemének korlátja (amelyből a legkevesebb kérés maradt).

  • X-RateLimit-Remaining

    A legszigorúbb korlát szerint még hátralévő kérések száma.

  • X-RateLimit-Reset

    A legszigorúbb korlát visszaállásáig hátralévő másodpercek.

application/json

Objektum: OAuthErrorResponse

Biztonságos újrapróbálkozás

Minden POST és PATCH kéréssel küldj Idempotency-Key fejlécet (például egy UUID-t). Ha 24 órán belül ugyanazzal a kulccsal megismétled a kérést, a mentett választ kapod vissza, és a kérés nem fut le újra.

Gyakorisági korlátok

A válaszokban ott van a RateLimit és a RateLimit-Policy fejléc, valamint a korábbi X-RateLimit-Limit, X-RateLimit-Remaining és X-RateLimit-Reset fejléc. A 429-es válasz Retry-After fejléce másodpercben adja meg a várakozást: várj, majd próbáld újra.

← oauth · API-referencia