CODEWITHSUNDEEP
spring-securityspring-authorization-server
Carl
Carl

Reputation: 618

Spring Authorization Server: Sending Opaque Token to Introspect endpoint returns "invalid_request"

I am migrating a project to Spring Authorization Server (1.0.0) and have hit an issue.

Despite the lack of much in the way of examples or documentation I have pressed ahead with trying to set it up to return Opaque tokens using the Authorization Code Flow (with PKCE).

I have managed to get the Scheme deployed and hook up all the services and have got to the point where my SPA can send a user to login on the Authorization server and use the code that comes back to get a token from the server.

The issues come when trying to send that access token to the introspect endpoint (I have not done any configuration on this it has been left as default).

Regardless of what tool I use (Spring Oauth2 Resource server or Postman) when I passs in the access token I am getting the following response.

{
    "error": "invalid_request"
}

I have confirmed that the access token exists in the oauth2_authorization table and that the correct client id & secret are being used (incorrect client id or secret on the introspection request returns a different error).

There are no errors shown in the console (regardless of log level) so I am getting a bit lost really.

The documentation seems really limited on this project so wanted to reach out to the community and see if anybody has any examples of how to setup opaque tokens or any ideas where I may be going wrong.

Upvotes: 0

Views: 2827

Answers (1)

Steve Riesenberg
Steve Riesenberg

Reputation: 6158

It sounds like we need an official sample or guide in the documentation to demonstrate this setup.

As it happens, we're presenting on this in our talk "Configuring and Extending Spring Authorization Server" at SpringOne Essentials in a few days (Jan 26, 2023). I cover both opaque tokens and token introspection in the upcoming talk.

The general approach I took to configure the Getting Started example is as follows:

  • Split the sample RegisteredClient into two clients called oidc-client and messaging-client
  • Leave oidc-client configured for OIDC, meaning it will remain configured to use JWTs
  • Change messaging-client to use opaque tokens with .tokenSettings(TokenSettings.builder().accessTokenFormat(OAuth2TokenFormat.REFERENCE).build())

The oidc-client would then be used just for logging in at the client, so it only needs scopes like openid and profile. The messaging-client would be used by the client to obtain an access token for accessing protected resources at the resource server, so it needs the scopes message.read and message.write in this example.

Splitting the RegisteredClient into two separate clients is necessary so that JWTs can continue to be used for the UserInfo endpoint[1].

See the following commits for the example:

[1] Note: It is actually a bit more difficult (though very possible) to configure Spring Authorization Server to use opaque tokens for the UserInfo endpoint. It involves configuring an OpaqueTokenIntrospector from Spring Security to introspect tokens internally. This would be a fairly advanced setup and possibly somewhat confusing, so we chose not to try and cover it in the talk.

Upvotes: 1

Related Questions