Optional Authorization in Introspection Endpoint

[rlanhellas]

In my company we are using a old version of Axway Security Token Services and this version don`t accept Authentication in check_token endpoint.

Reading the code I discovered that in this point (https://github.com/spring-projects/spring-security-oauth/blob/master/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/provider/token/RemoteTokenServices.java) the method loadAuthentication() is loading the credentials:

MultiValueMap<String, String> formData = new LinkedMultiValueMap<String, String>(); formData.add(tokenName, accessToken); HttpHeaders headers = new HttpHeaders(); headers.set("Authorization", getAuthorizationHeader(clientId, clientSecret));

I know this follow the RFC Token Introspection but in our case we need override this method to work with this version of Axway STS that don`t follow RFC as expected (unhappy).

I would like to know if I can open a Merge Request to give an option to remove the Authorization when needed.

[OrangeDog]

I've not checked, but maybe setting .checkTokenAccess("allowAll()") would work for you?

[jgrandja]

@rlanhellas This project is in maintenance mode and will be retired in the near future. So we are not accepting new feature requests. Please see this announcement. I would encourage you to use the new OAuth 2.0 support in Spring Security 5.

[rlanhellas]

Thanks Joe, I will see if this feature is present in spring security 5

[rlanhellas]

I've not checked, but maybe setting .checkTokenAccess("allowAll()") would work for you?

No, because this change should be made in Authorization Server and I just can change the client.

[jgrandja]

@rlanhellas See OpaqueTokenIntrospector https://docs.spring.io/spring-security/site/docs/5.3.0.RC1/reference/html5/#oauth2resourceserver-opaque-sansboot

[rlanhellas]

@rlanhellas See OpaqueTokenIntrospector https://docs.spring.io/spring-security/site/docs/5.3.0.RC1/reference/html5/#oauth2resourceserver-opaque-sansboot

The only problem I see in my case is that I need create a OpaqueTokenIntrospector class to avoid send credentials to my URL (basic auth). So, for me, the better way should only not pass client ID and client secret and spring security understand that I don't have a security URL, or create a flag to ignore authorization in introspection URL.

[OrangeDog]

@jgrandja on that topic, it still says

Due to this feedback and some internal discussions, we are taking another look at this decision. We’ll notify the community on any progress.

Where will that notification appear?

[jgrandja]

@OrangeDog We've been quite busy with Spring Security 5.3, which is being released March 4. We're starting our internal meetings next week and will provide an update soon, as far as Authorization Server support in Spring Security. You will see a follow-up blog post and a link to it in spring-security#6320.

To be clear, this project will still be discontinued in the near future. There will be no changes to the decision on deprecating this project.

[jgrandja]

@rlanhellas

I need create a OpaqueTokenIntrospector class to avoid send credentials to my URL (basic auth)

I would not recommend this. The Authorization Server really should protected/secure this endpoint. The spec also states the following in 2.1. Introspection Request:

To prevent token scanning attacks, the endpoint MUST also require
some form of authorization to access this endpoint, such as client
authentication as described in OAuth 2.0 [RFC6749] or a separate
OAuth 2.0 access token such as the bearer token described in OAuth
2.0 Bearer Token Usage [RFC6750]

[rlanhellas]

Yes, the Authorization Server should protect this endpoint ( I agree with it), but in some authorization providers, like axway (old version) this is not protected.

[rlanhellas]

@rlanhellas

I need create a OpaqueTokenIntrospector class to avoid send credentials to my URL (basic auth)

I would not recommend this. The Authorization Server really should protected/secure this endpoint. The spec also states the following in 2.1. Introspection Request:

To prevent token scanning attacks, the endpoint MUST also require
some form of authorization to access this endpoint, such as client
authentication as described in OAuth 2.0 [RFC6749] or a separate
OAuth 2.0 access token such as the bearer token described in OAuth
2.0 Bearer Token Usage [RFC6750]

May I suggest a merge request to add this flag in spring security 5.x ?

[jgrandja]

@rlanhellas You certainly could suggest an update to Spring Security 5.x and we'll see what we could do to accommodate.