RFC9449 introduces a way to constraint tokens (access_token, refresh_token) to a client provided pub key.
For a resource server (implemented using spring security) it would be really useful to implement in addition to bearer authentication the DPoP Authentication scheme
Note: Nimbus contains already support for producing DPoP JWT(s) & validating them
Comment From: sjohnr
Thanks for opening this @babisRoutis. I am marking this for consideration in a future release.
Comment From: babisRoutis
Thanks for opening this @babisRoutis. I am marking this for consideration in a future release.
Hi @sjohnr happy to hear that this is for consideration.
With regards to DPoP there are two features that you can consider:
- Support DPoP Authentication Scheme in Spring Authorization Server.
- Support DPoP scheme in a Protected Resource (that uses spring security). Typically, this includes checking the DPoP Access token using the introspection endpoint of the authorization server, verifying the DPoP JWT (from the Http header) and finally checking that the htu claim corresponds to a spring route.
Comment From: sjohnr
Thanks @babisRoutis.
Support DPoP Authentication Scheme in Spring Authorization Server.
For that, please feel free to open an issue over there since this issue tracker is just for the Spring Security side.
Comment From: ThomasKasene
I'd say this issue should also include DPoP support for the OAuth2 clients out there π
In fact, I'm struggling with implementing this right now, and I'm being stopped dead in my tracks due to the strictness of Spring Security. Would it be possible to introduce a new constant in OAuth2AccessToken.TokenType as a kind of initial support? π
public static final TokenType BEARER = new TokenType("Bearer");
public static final TokenType DPOP = new TokenType("DPoP"); // new
I can't make this in my own code because the constructor is private, and I need it to create a new OAuth2AccessTokenResponseConverter that can handle a token_type of DPoP in the token response (see RFC 9449).
Comment From: sjohnr
@ThomasKasene thanks for the input.
Would it be possible to introduce a new constant in
OAuth2AccessToken.TokenTypeas a kind of initial support? π
Absolutely, that makes sense to me. Would you be interested in opening a PR for this? If so, make sure to reference this issue in the commit comment as "Issue gh-14915".
I think it also makes sense to open an issue to consider making the constructor public. I'll do that now.
Comment From: ThomasKasene
Would you be interested in opening a PR for this?
Done via gh-16087 π
Comment From: jgrandja
@babisRoutis I added spring-authorization-server#1813
Comment From: jkuipers
I'd say this issue should also include DPoP support for the OAuth2 clients out there π
I have the same issue: a client wants to use Okta with a configuration that requires DPoP for a traditional server-side web application. That means they don't require support for validating DPoP tokens provided by clients, but their application is itself the client that needs to interact with Okta both for obtaining an access token AND for then securily interacting with the /userinfo endpoint. I spent some time this week on getting this to work, and I've documented the results in this blog post: Maybe it can be of help to see where I had to overwrite/extend the current OIDC support.
Comment From: sjohnr
Thanks @jkuipers. That's very helpful for folks, so thanks for doing that.
Regarding this issue, I am tentatively targeting this for the 6.5 release. It currently only has 8 upvotes but it's only been open a few months and this is an important one to make sure folks at least have an easier time integrating with this RFC in Spring Security.
There are two distinct issues here: OAuth2 Resource Server support and OAuth2 Client support. I'm going to leave this issue alone for now to represent both. Later, we can split into two separate issues in case one can get done sooner than the other. In fact, we can just use a PR as the separate issue.
Comment From: jgrandja
Closing this as a duplicate of gh-16574