Michel-Marie MAUDET
f0493a7ba8
Some checks failed
Documentation / Build and Deploy Documentation (push) Successful in 1m8s
Checks / Prek / Pre-commit & Formatting (push) Successful in 1m12s
Checks / Prek / Check changed files (push) Successful in 8s
Release Docker Image / Build linux-amd64 (release) (push) Failing after 3m39s
Release Docker Image / Build linux-arm64 (release) (push) Successful in 12m40s
Release Docker Image / Create Multi-arch Release Manifest (push) Has been skipped
Release Docker Image / Build linux-amd64 (max-perf) (push) Has been skipped
Release Docker Image / Build linux-arm64 (max-perf) (push) Has been skipped
Release Docker Image / Create Max-Perf Manifest (push) Has been skipped
Release Docker Image / Mirror Images (push) Has been skipped
Release Docker Image / Release Binaries (push) Has been skipped
Checks / Prek / Clippy and Cargo Tests (push) Successful in 10m21s
The token endpoint already refused grant types the client had not registered, but reported it as `invalid_grant`. RFC 6749 section 5.2 reserves `invalid_grant` for an authorization grant which is "invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client", and defines `unauthorized_client` for a client which "is not authorized to use this authorization grant type". Report the condition with the error code the specification assigns to it, matching the device authorization endpoint.
332 B
332 B
The OAuth 2.0 device authorization endpoint now rejects clients which did not register the device code grant type, instead of issuing them a device code. The token endpoint now returns the unauthorized_client error code when a client requests a grant type it did not register, instead of invalid_grant. Contributed by @mmaudet.