Add different authentication options for the token revocation endpoint

[andreygrigoriev]

Hi! First of all I would like to thank you for the great job. Spring Authorization Server is awesome

Expected Behavior
It would be great if Spring Authorization Server supported client_secret_post and none client authentication methods for token revocation endpoint.

Current Behavior
As of now Spring Authorization Server supports only basic authentication for the /oauth2/revoke endpoint, and you cannot call this endpoint without specifying a client secret in the basic auth header.

Context
It's becoming a problem when you have public clients. Keycloak for example provides an option to specify client credentials in the request body as well as in the basic auth header, and allows to omit the client secret parameter.

[mahdiraddadi]

I confirm the issue, but they followed the OAuth2 specifications,
I configured the token revokation but I used the resource server to logout from my angular app in order to store the client secret in a safe way

[andreygrigoriev]

https://datatracker.ietf.org/doc/html/rfc7009#page-4
It does not require to specify credentials in the auth header:

The client also includes its authentication credentials as described
in Section 2.3. of [RFC6749].

2.3. Client Authentication

If the client type is confidential, the client and authorization
server establish a client authentication method suitable for the
security requirements of the authorization server. The authorization
server MAY accept any form of client authentication meeting its
security requirements.

Confidential clients are typically issued (or establish) a set of
client credentials used for authenticating with the authorization
server (e.g., password, public/private key pair).

The authorization server MAY establish a client authentication method
with public clients. However, the authorization server MUST NOT rely
on public client authentication for the purpose of identifying the
client.

The client MUST NOT use more than one authentication method in each
request.

[sjohnr]

Hi @andreygrigoriev, thanks for your interest in the project!

Please also note, from RFC 7009, Section 2.1:

The authorization server first validates the client credentials (in
case of a confidential client) and then verifies whether the token
was issued to the client making the revocation request. If this
validation fails, the request is refused and the client is informed
of the error by the authorization server as described below.

The only way a public client could prove it was the client that was originally issued the access token would be to provide the PKCE code verifier again. However, I'm not aware of anything in the specification that details using PKCE parameters as a longer term type of credential (e.g. valid as long as the access token is not expired). If there is, that could be something to look into.

As it sits currently however, I'm going to close this as per this comment. Similar to what was shared by @mahdiraddadi, you would want to follow recommendations in gh-297 for guidelines on integrating a single-page app, specifically focusing on using the "backend for frontend" pattern to securely integrate with the authorization server.

[sjohnr]

One additional note. I'm assuming that this:

It would be great if Spring Authorization Server supported client_secret_post

is already supported because the OAuth2TokenRevocationEndpointFilter relies on the OAuth2ClientAuthenticationFilter which supports client_secret_post. If I'm incorrect in that, please let me know and we can re-open to investigate further.

[pstorch]

Shouldn't it be possible to revoke the access_token by a public client? Even if the access_token got leaked, it can be used to perform far more malicious actions (at the RS) than revoking it at the (AS).

[jgrandja]

@pstorch

Shouldn't it be possible to revoke the access_token by a public client?

Yes it is possible but this would need to be customized by the consuming application. A custom AuthenticationConverter and AuthenticationProvider would need to be implemented and configured via the OAuth2ClientAuthenticationConfigurer.