Gå til indholdet
Sursa Developers

POST/oauth/token

Udsted et OAuth 2.0-token

oauth_token

Tokenoperationen i OAuth 2.0 (RFC 6749, afsnit 3.2). grant_type: authorization_code veksler en engangskode til et tokenpar og kræver code_verifier (PKCE S256); refresh_token udsteder et nyt par for et opdateringstoken og ugyldiggør det tidligere opdateringstoken (rotation), og genbrug af et ugyldiggjort token tilbagekalder hele kæden; client_credentials udsteder et token på vegne af organisationen, kun for en app af typen confidential og uden opdateringstoken. En klient af typen confidential autentificerer sig med headeren Authorization: Basic eller med felterne client_id og client_secret; en offentlig klient sender kun client_id. Et adgangstoken er gyldigt i 1 time, et opdateringstoken i 90 dage. Svar og fejl følger RFC 6749, afsnit 5, med Cache-Control: no-store. Tilføjet i 1.62.0.

Autentificering

Kræver ingen legitimationsoplysninger.

Anmodningens brødtekst

application/x-www-form-urlencoded

Objekt: OAuthTokenRequest

  • grant_typestringpåkrævet

    Tilladte værdier: authorization_coderefresh_tokenclient_credentials

  • codestring

    Autorisationskode (authorization_code).

  • redirect_uristring

    Den samme omdirigerings-URI som i autorisationsanmodningen (authorization_code).

  • code_verifierstring

    Den oprindelige PKCE-værdi, 43 til 128 tegn (authorization_code).

  • refresh_tokenstring

    Opdateringstoken (refresh_token).

  • scopestring

    Mellemrumsseparerede scopes, kun til indsnævring (refresh_token, client_credentials).

  • client_idstring

    Appens id, når hemmeligheden ikke angives i headeren Authorization: Basic.

  • client_secretstring

    Klienthemmelighed for en app af typen confidential, når den ikke angives i headeren Authorization: Basic.

Svar

200Tokens blev udstedt.

Svarets headere

  • RateLimit-Policy

    Gældende grænser i formatet fra IETF-udkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerede elementer "<name>";q=<quota>;w=<window in seconds>. key er API-nøglens anmodningshastighed (kvoten er burst, vinduet er tiden til fuld genopfyldning; for en session er det user, uden legitimationsoplysninger ip); minute, day og month er organisationens kvoter for kalenderminuttet, kalenderdagen og kalendermåneden i UTC.

  • RateLimit

    Hvad der er tilbage af hver grænse i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Grænsen for den strengeste post i RateLimit-Policy (den med færrest resterende anmodninger).

  • X-RateLimit-Remaining

    Resterende anmodninger under den strengeste grænse.

  • X-RateLimit-Reset

    Sekunder, til den strengeste grænse nulstilles.

application/json

Objekt: OAuthTokenResponse

  • access_tokenstringpåkrævet

    Adgangstoken (kbat_…) til headeren Authorization: Bearer.

  • token_typestringpåkrævet

    Tilladte værdier: Bearer

  • expires_inintegerpåkrævet

    Adgangstokenets levetid i sekunder.

  • refresh_tokenstring

    Opdateringstoken (kbrt_…); mangler for client credentials.

  • scopestringpåkrævet

    Tokenets scopes, adskilt af mellemrum.

400Fejl som defineret i RFC 6749, afsnit 5.2.

Svarets headere

  • RateLimit-Policy

    Gældende grænser i formatet fra IETF-udkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerede elementer "<name>";q=<quota>;w=<window in seconds>. key er API-nøglens anmodningshastighed (kvoten er burst, vinduet er tiden til fuld genopfyldning; for en session er det user, uden legitimationsoplysninger ip); minute, day og month er organisationens kvoter for kalenderminuttet, kalenderdagen og kalendermåneden i UTC.

  • RateLimit

    Hvad der er tilbage af hver grænse i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Grænsen for den strengeste post i RateLimit-Policy (den med færrest resterende anmodninger).

  • X-RateLimit-Remaining

    Resterende anmodninger under den strengeste grænse.

  • X-RateLimit-Reset

    Sekunder, til den strengeste grænse nulstilles.

application/json

Objekt: OAuthErrorResponse

401Ugyldige klientlegitimationsoplysninger (`invalid_client`).

Svarets headere

  • RateLimit-Policy

    Gældende grænser i formatet fra IETF-udkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerede elementer "<name>";q=<quota>;w=<window in seconds>. key er API-nøglens anmodningshastighed (kvoten er burst, vinduet er tiden til fuld genopfyldning; for en session er det user, uden legitimationsoplysninger ip); minute, day og month er organisationens kvoter for kalenderminuttet, kalenderdagen og kalendermåneden i UTC.

  • RateLimit

    Hvad der er tilbage af hver grænse i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Grænsen for den strengeste post i RateLimit-Policy (den med færrest resterende anmodninger).

  • X-RateLimit-Remaining

    Resterende anmodninger under den strengeste grænse.

  • X-RateLimit-Reset

    Sekunder, til den strengeste grænse nulstilles.

application/json

Objekt: OAuthErrorResponse

Sikre nye forsøg

Send en Idempotency-Key-header (fx et UUID) med hver POST og PATCH. Et nyt forsøg med den samme nøgle inden for 24 timer returnerer det gemte svar i stedet for at køre anmodningen igen.

Hastighedsgrænser

Svarene har headerne RateLimit og RateLimit-Policy samt de tidligere X-RateLimit-Limit, X-RateLimit-Remaining og X-RateLimit-Reset. Et 429-svar har Retry-After i sekunder: Vent, og forsøg igen.

← oauth · API-reference