Skip to content

Conversation

@franticticktick
Copy link
Contributor

Closes gh-16940

Closes spring-projectsgh-16940

Signed-off-by: Max Batischev <mblancer@mail.ru>
@franticticktick franticticktick marked this pull request as draft June 3, 2025 10:33
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 3, 2025
@jgrandja jgrandja self-assigned this Jun 5, 2025
@jgrandja jgrandja added type: enhancement A general enhancement in: oauth2 An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose) and removed status: waiting-for-triage An issue we've not yet triaged labels Jun 5, 2025
@jgrandja jgrandja added this to the 7.0.0-M1 milestone Jun 5, 2025
@jgrandja
Copy link
Contributor

jgrandja commented Jun 5, 2025

Thanks for the PR @franticticktick. I will review this soon.

@jgrandja jgrandja modified the milestones: 7.0.0-M1, 7.0.x Jun 16, 2025
@jgrandja jgrandja modified the milestones: 7.0.x, 7.1.0-M1 Nov 12, 2025
@jgrandja
Copy link
Contributor

Thanks for your patience @franticticktick and apologies that I could not get this into 7.0. We had quite a workload for this round of majors.

I have scheduled this for 7.1.0-M1 and will review this soon. In the meantime, when you have a moment can you please rebase. Thank you.

@renannprado
Copy link

renannprado commented Nov 24, 2025

@franticticktick @jgrandja I haven't gone through the details of the PR, but I just wanted to add the following:

It's not uncommon for ppl to have a reverse proxy in front of their applications, having a reverse proxy could mean (like in my use case) that you have different paths per application. For example, https://api.example.com/svc1/* routes requests to application svc1 and https://api.example.com/svc2/*routes requests to application svc2. The problem here is that normally applications would sign the DPoP for https://api.example.com/svc2/my-api and not https://api.example.com/my-api. So when Spring Security's DPoP validation kicks in, it will look at the URL https://api.example.com/svc2/my-api and find no endpoint matching that URL, because the application doesn't know about /svc2/my-api. Now our current workaround is that our frontends replace the first path segment of the URL so that they send the request to /svc2/my-api, but sign the DPoP for /my-api, but IMHO frontends should be aware of the reverse proxy whatsoever.

TL;DR it should be possible to customize the DPoP validation to be reverse-proxy aware. I'm just trying to scratch my itch here, but I do believe this is not an uncommon use case. I'm happy to contribute somehow if needed.

Edit:

Also, can we also get this into the 6.5.x?

@ferrerogg
Copy link

TL;DR it should be possible to customize the DPoP validation to be reverse-proxy aware. I'm just trying to scratch my itch here, but I do believe this is not an uncommon use case. I'm happy to contribute somehow if needed.

I've a similar setup where reverse proxy is Spring Cloud Gateway 5 MVC. You must configure your reverse proxy to add X-Forwarded-xxxx headers (in your case, X-Forwarded-Prefix should report /svc1 or /svc2 to your resource server).
In my setup, I've configured my resource server with server.forward-headers-strategy = framework and it works as expected (see Running Behind a Front-end Proxy Server)

@renannprado
Copy link

@ferrerogg it worked. Thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

in: oauth2 An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose) type: enhancement A general enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add support dpop customization

5 participants