Hopp til innholdet
Sursa Developers

POST/oauth/token

Utsted et OAuth 2.0-token

oauth_token

OAuth 2.0-operasjonen for tokener (RFC 6749, avsnitt 3.2). grant_type: authorization_code bytter en engangskode mot et tokenpar og krever code_verifier (PKCE S256); refresh_token utsteder et nytt par for et oppdateringstoken og gjør det forrige oppdateringstokenet ugyldig (rotasjon), og gjenbruk av et ugyldiggjort token trekker tilbake hele kjeden; client_credentials utsteder et token på vegne av organisasjonen, bare for en confidential-app, uten oppdateringstoken. En confidential-klient autentiserer seg med headeren Authorization: Basic eller med feltene client_id og client_secret; en offentlig klient sender bare client_id. Et tilgangstoken er gyldig i 1 time, et oppdateringstoken i 90 dager. Svar og feil følger RFC 6749, avsnitt 5, med Cache-Control: no-store. Lagt til i 1.62.0.

Autentisering

Krever ingen påloggingsinformasjon.

Forespørselens brødtekst

application/x-www-form-urlencoded

Objekt: OAuthTokenRequest

  • grant_typestringobligatorisk

    Tillatte verdier: authorization_coderefresh_tokenclient_credentials

  • codestring

    Autorisasjonskode (authorization_code).

  • redirect_uristring

    Den samme omdirigerings-URI-en som i autorisasjonsforespørselen (authorization_code).

  • code_verifierstring

    Den opprinnelige PKCE-verdien, 43 til 128 tegn (authorization_code).

  • refresh_tokenstring

    Oppdateringstoken (refresh_token).

  • scopestring

    Scopes adskilt med mellomrom, bare innsnevring (refresh_token, client_credentials).

  • client_idstring

    Appens ID, når hemmeligheten ikke sendes i headeren Authorization: Basic.

  • client_secretstring

    Klienthemmeligheten til en app av typen confidential, når den ikke sendes i headeren Authorization: Basic.

Svar

200Tokenene ble utstedt.

Headere i svaret

  • RateLimit-Policy

    Gjeldende grenser i formatet fra IETF-utkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerte elementer "<name>";q=<quota>;w=<window in seconds>. key er forespørselsraten til API-nøkkelen (kvoten er burst, tidsvinduet er tiden det tar å fylle den helt opp igjen; for en økt er det user, uten påloggingsinformasjon ip); minute, day og month er organisasjonens kvoter for kalenderminuttet, kalenderdøgnet og kalendermåneden i UTC.

  • RateLimit

    Hva som gjenstår av hver grense i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Grensen for den strengeste oppføringen i RateLimit-Policy (den med færrest gjenværende forespørsler).

  • X-RateLimit-Remaining

    Gjenværende forespørsler under den strengeste grensen.

  • X-RateLimit-Reset

    Sekunder til den strengeste grensen nullstilles.

application/json

Objekt: OAuthTokenResponse

  • access_tokenstringobligatorisk

    Tilgangstoken (kbat_…) for headeren Authorization: Bearer.

  • token_typestringobligatorisk

    Tillatte verdier: Bearer

  • expires_inintegerobligatorisk

    Tilgangstokenets levetid i sekunder.

  • refresh_tokenstring

    Oppdateringstoken (kbrt_…); mangler for klientlegitimasjon.

  • scopestringobligatorisk

    Tokenets scopes adskilt med mellomrom.

400Feil som definert i RFC 6749, avsnitt 5.2.

Headere i svaret

  • RateLimit-Policy

    Gjeldende grenser i formatet fra IETF-utkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerte elementer "<name>";q=<quota>;w=<window in seconds>. key er forespørselsraten til API-nøkkelen (kvoten er burst, tidsvinduet er tiden det tar å fylle den helt opp igjen; for en økt er det user, uten påloggingsinformasjon ip); minute, day og month er organisasjonens kvoter for kalenderminuttet, kalenderdøgnet og kalendermåneden i UTC.

  • RateLimit

    Hva som gjenstår av hver grense i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Grensen for den strengeste oppføringen i RateLimit-Policy (den med færrest gjenværende forespørsler).

  • X-RateLimit-Remaining

    Gjenværende forespørsler under den strengeste grensen.

  • X-RateLimit-Reset

    Sekunder til den strengeste grensen nullstilles.

application/json

Objekt: OAuthErrorResponse

401Ugyldig klientlegitimasjon (`invalid_client`).

Headere i svaret

  • RateLimit-Policy

    Gjeldende grenser i formatet fra IETF-utkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerte elementer "<name>";q=<quota>;w=<window in seconds>. key er forespørselsraten til API-nøkkelen (kvoten er burst, tidsvinduet er tiden det tar å fylle den helt opp igjen; for en økt er det user, uten påloggingsinformasjon ip); minute, day og month er organisasjonens kvoter for kalenderminuttet, kalenderdøgnet og kalendermåneden i UTC.

  • RateLimit

    Hva som gjenstår av hver grense i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Grensen for den strengeste oppføringen i RateLimit-Policy (den med færrest gjenværende forespørsler).

  • X-RateLimit-Remaining

    Gjenværende forespørsler under den strengeste grensen.

  • X-RateLimit-Reset

    Sekunder til den strengeste grensen nullstilles.

application/json

Objekt: OAuthErrorResponse

Trygge nye forsøk

Send en Idempotency-Key-header (for eksempel en UUID) med hver POST og PATCH. Et nytt forsøk med samme nøkkel innen 24 timer returnerer det lagrede svaret i stedet for å kjøre forespørselen på nytt.

Hastighetsgrenser

Svarene har headerne RateLimit og RateLimit-Policy og de eldre X-RateLimit-Limit, X-RateLimit-Remaining og X-RateLimit-Reset. Et 429-svar har Retry-After i sekunder: Vent, og prøv på nytt.

← oauth · API-referanse