Back-Channel Logout Response and the HTTP success status code
Issue #1486
resolved
The section states that
If the logout succeeded, the RP MUST respond with HTTP 200 OK.
However, HTTP POST requests are also associated with the “creating of a new resource“ operation, and accordingly, there is a special status for that - 201 (Created).
Why does this specification tie to HTTP 200 OK? Is it really necessary?
Comments (5)
-
-
200 OK is what is defined by the spec, it is too late to change it. I agree 201 does not apply.
However, since we do not dictate any body to be present in the response there’s the point to be made that a 204 No Content fits better.
I have recently been made aware of web frameworks and edge providers who, despite the application developer saying I wish to respond with 200 OK, unless they explicitly provide a body, will change empty body responses from 200 to 204 on the account of the response having no content and it being some sort of convention.
I would say to keep the 200 OK, but add a note that the OP’s MAY or SHOULD (up to you) also accept a 204 if/since? the response has no body.
-
reporter
In practice, it isn’t uncommon to see the code like
if code := r.StatusCode; code < 200 || code > 299 { return nil, &RetrieveError{ Response: r, Body: body, } }I took this snippet from the official GoLang OAuth2 package.
It accepts any 2** HTTP code as a successful response from the AS.
As a (random) side comment, OAuth and OpenID Connect endpoints aren’t truly REST APIs but it’s OK to respond with 201 for the POST requests. It’s recommended to do per various REST API guidelines, for example, from Microsoft.
-
-
- changed status to resolved
- Log in to comment
For starters, a logout doesn’t create a new resource, so a 201 (Created) wouldn’t apply.
Secondly, standards are about making choices to enhance interoperability. The specification chose 200 (OK) as the success code. Implementations can count on that. There’s no reason to make them process multiple different success codes when using one is simpler.