2019-04-22 08:38:41 -04:00
|
|
|
[role="xpack"]
|
|
|
|
|
[[security-api-oidc-logout]]
|
2019-08-02 13:56:05 -04:00
|
|
|
=== OpenID Connect logout API
|
2019-04-22 08:38:41 -04:00
|
|
|
|
2019-08-02 13:56:05 -04:00
|
|
|
Submits a request to invalidate a refresh token and an access token that was
|
[7.x] Fix responses for the token APIs (#54532) (#55278)
This commit fixes our behavior regarding the responses we
return in various cases for the use of token related APIs.
More concretely:
- In the Get Token API with the `refresh` grant, when an invalid
(already deleted, malformed, unknown) refresh token is used in the
body of the request, we respond with `400` HTTP status code
and an `error_description` header with the message "could not
refresh the requested token".
Previously we would return erroneously return a `401` with "token
malformed" message.
- In the Invalidate Token API, when using an invalid (already
deleted, malformed, unknown) access or refresh token, we respond
with `404` and a body that shows that no tokens were invalidated:
```
{
"invalidated_tokens":0,
"previously_invalidated_tokens":0,
"error_count":0
}
```
The previous behavior would be to erroneously return
a `400` or `401` ( depending on the case ).
- In the Invalidate Token API, when the tokens index doesn't
exist or is closed, we return `400` because we assume this is
a user issue either because they tried to invalidate a token
when there is no tokens index yet ( i.e. no tokens have
been created yet or the tokens index has been deleted ) or the
index is closed.
- In the Invalidate Token API, when the tokens index is
unavailable, we return a `503` status code because
we want to signal to the caller of the API that the token they
tried to invalidate was not invalidated and we can't be sure
if it is still valid or not, and that they should try the request
again.
Resolves: #53323
2020-04-16 07:05:55 -04:00
|
|
|
generated as a response to a call to `/_security/oidc/authenticate`.
|
2019-04-22 08:38:41 -04:00
|
|
|
|
2019-08-02 13:56:05 -04:00
|
|
|
[[security-api-oidc-logout-request]]
|
|
|
|
|
==== {api-request-title}
|
2019-04-22 08:38:41 -04:00
|
|
|
|
2019-08-02 13:56:05 -04:00
|
|
|
`POST /_security/oidc/logout`
|
2019-04-22 08:38:41 -04:00
|
|
|
|
2019-08-02 13:56:05 -04:00
|
|
|
[[security-api-oidc-logout-desc]]
|
|
|
|
|
==== {api-description-title}
|
2019-04-22 08:38:41 -04:00
|
|
|
|
2019-08-02 13:56:05 -04:00
|
|
|
If the OpenID Connect authentication realm in {es} is accordingly configured,
|
|
|
|
|
the response to this call will contain a URI pointing to the End Session
|
|
|
|
|
Endpoint of the OpenID Connect Provider in order to perform Single Logout.
|
|
|
|
|
|
|
|
|
|
{es} exposes all the necessary OpenID Connect related functionality via the
|
|
|
|
|
OpenID Connect APIs. These APIs are used internally by {kib} in order to provide
|
|
|
|
|
OpenID Connect based authentication, but can also be used by other, custom web
|
|
|
|
|
applications or other clients. See also
|
|
|
|
|
<<security-api-oidc-authenticate,OpenID Connect authenticate API>>
|
|
|
|
|
and
|
|
|
|
|
<<security-api-oidc-prepare-authentication,OpenID Connect prepare authentication API>>.
|
2019-04-22 08:38:41 -04:00
|
|
|
|
2019-08-02 13:56:05 -04:00
|
|
|
[[security-api-oidc-logout-request-body]]
|
|
|
|
|
==== {api-request-body-title}
|
2019-04-22 08:38:41 -04:00
|
|
|
|
|
|
|
|
`access_token`::
|
2019-08-25 12:36:41 -04:00
|
|
|
(Required, string) The value of the access token to be invalidated as part of the logout.
|
2019-04-22 08:38:41 -04:00
|
|
|
|
|
|
|
|
`refresh_token`::
|
2019-08-25 12:36:41 -04:00
|
|
|
(Optional, string) The value of the refresh token to be invalidated as part of the logout.
|
2019-04-22 08:38:41 -04:00
|
|
|
|
|
|
|
|
|
2019-08-02 13:56:05 -04:00
|
|
|
[[security-api-oidc-logout-example]]
|
|
|
|
|
==== {api-examples-title}
|
2019-04-22 08:38:41 -04:00
|
|
|
|
|
|
|
|
The following example performs logout
|
|
|
|
|
|
2019-09-05 14:12:39 -04:00
|
|
|
[source,console]
|
2019-04-22 08:38:41 -04:00
|
|
|
--------------------------------------------------
|
|
|
|
|
POST /_security/oidc/logout
|
|
|
|
|
{
|
|
|
|
|
"token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==",
|
|
|
|
|
"refresh_token": "vLBPvmAB6KvwvJZr27cS"
|
|
|
|
|
}
|
|
|
|
|
--------------------------------------------------
|
[7.x] Fix responses for the token APIs (#54532) (#55278)
This commit fixes our behavior regarding the responses we
return in various cases for the use of token related APIs.
More concretely:
- In the Get Token API with the `refresh` grant, when an invalid
(already deleted, malformed, unknown) refresh token is used in the
body of the request, we respond with `400` HTTP status code
and an `error_description` header with the message "could not
refresh the requested token".
Previously we would return erroneously return a `401` with "token
malformed" message.
- In the Invalidate Token API, when using an invalid (already
deleted, malformed, unknown) access or refresh token, we respond
with `404` and a body that shows that no tokens were invalidated:
```
{
"invalidated_tokens":0,
"previously_invalidated_tokens":0,
"error_count":0
}
```
The previous behavior would be to erroneously return
a `400` or `401` ( depending on the case ).
- In the Invalidate Token API, when the tokens index doesn't
exist or is closed, we return `400` because we assume this is
a user issue either because they tried to invalidate a token
when there is no tokens index yet ( i.e. no tokens have
been created yet or the tokens index has been deleted ) or the
index is closed.
- In the Invalidate Token API, when the tokens index is
unavailable, we return a `503` status code because
we want to signal to the caller of the API that the token they
tried to invalidate was not invalidated and we can't be sure
if it is still valid or not, and that they should try the request
again.
Resolves: #53323
2020-04-16 07:05:55 -04:00
|
|
|
// TEST[catch:request]
|
2019-04-22 08:38:41 -04:00
|
|
|
|
2019-08-02 13:56:05 -04:00
|
|
|
The following example output of the response contains the URI pointing to the
|
|
|
|
|
End Session Endpoint of the OpenID Connect Provider with all the parameters of
|
|
|
|
|
the Logout Request, as HTTP GET parameters:
|
2019-04-22 08:38:41 -04:00
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
{
|
|
|
|
|
"redirect" : "https://op-provider.org/logout?id_token_hint=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c&post_logout_redirect_uri=http%3A%2F%2Foidc-kibana.elastic.co%2Floggedout&state=lGYK0EcSLjqH6pkT5EVZjC6eIW5YCGgywj2sxROO"
|
|
|
|
|
}
|
|
|
|
|
--------------------------------------------------
|
[7.x] Fix responses for the token APIs (#54532) (#55278)
This commit fixes our behavior regarding the responses we
return in various cases for the use of token related APIs.
More concretely:
- In the Get Token API with the `refresh` grant, when an invalid
(already deleted, malformed, unknown) refresh token is used in the
body of the request, we respond with `400` HTTP status code
and an `error_description` header with the message "could not
refresh the requested token".
Previously we would return erroneously return a `401` with "token
malformed" message.
- In the Invalidate Token API, when using an invalid (already
deleted, malformed, unknown) access or refresh token, we respond
with `404` and a body that shows that no tokens were invalidated:
```
{
"invalidated_tokens":0,
"previously_invalidated_tokens":0,
"error_count":0
}
```
The previous behavior would be to erroneously return
a `400` or `401` ( depending on the case ).
- In the Invalidate Token API, when the tokens index doesn't
exist or is closed, we return `400` because we assume this is
a user issue either because they tried to invalidate a token
when there is no tokens index yet ( i.e. no tokens have
been created yet or the tokens index has been deleted ) or the
index is closed.
- In the Invalidate Token API, when the tokens index is
unavailable, we return a `503` status code because
we want to signal to the caller of the API that the token they
tried to invalidate was not invalidated and we can't be sure
if it is still valid or not, and that they should try the request
again.
Resolves: #53323
2020-04-16 07:05:55 -04:00
|
|
|
// NOTCONSOLE
|
