Expose getter for nameAttributeKey in OAuth2AuthenticatedPrincipal

[andreblanke]

Given a DefaultOidcUser or DefaultOAuth2User, it is currently not possible to create a faithful copy of the instance since the constructors require a nameAttributeKey for the all-arg constructor:

public DefaultOidcUser(Collection<? extends GrantedAuthority> authorities, OidcIdToken idToken,
		String nameAttributeKey)

public DefaultOAuth2User(Collection<? extends GrantedAuthority> authorities, Map<String, Object> attributes,
		String nameAttributeKey)

which is not accessible.

This issue has been mentioned before in #14461 (comment) where a custom ExtendedOidcUser decorator class is used to work around it. While that works, I feel that this should be possible without introducing a separate class using just the public API.

The PR aims to change this by adding the OAuth2AuthenticatedPrincipal.getNameAttributeKey method in 464b078. This is a breaking change for classes implementing the interface.

With the nameAttributeKey now available from within the interface, I figured it also makes sense to provide a default implementation for OAuth2AuthenticatedPrincipal.getName in c7bcf86.

[jzheaux]

Thanks, @andreblanke! I've left some feedback inline.

[jzheaux]

Hi, @andreblanke! Are you able to make the requested changes? No rush, if I don't hear from you in about a week, I'm happy to make the changes myself.

[andreblanke]

Hi there @jzheaux. First of all thank you for your feedback. Sorry, I've been postponing this. I'd like to finish the changes in the next few days once we've decided on an implementation (getter for nameAttributeKey vs. new constructors).

[jzheaux]

Thanks for the updates, @andreblanke! I've left some feedback inilne.

[jzheaux]

Hi, @andreblanke. Thanks for doing all this research with me, I appreciate your contributions. At this point, I think it's pretty clear that this approach is too complex to address your much simpler concern. I think deprecation will need to wait for another time.

Can you confirm that this is what you are effectively needing:

DefaultOAuth2User user = new DefaultOAuth2User(...);
DefaultOAuth2User copy = // ... copy the values somehow
assert user.equals(copy);
assert user != copy;

If so, I think we can do something much simpler, which is add a copy constructor to each class:

DefaultOAuth2User user = new DefaultOAuth2User(...);
DefaultOAuth2User copy = new DefaultOAuth2User(user);
assert user.equals(copy);
assert user != copy;

// ... same for DefaultOidcUser

If you can confirm that this would work, I will push a change along these lines and have you review it. If not, please feel free to explain more of your use case so we can find a better fit together.

[andreblanke]

Hi @jzheaux. First of all thank your for your guidance so far. Sorry the PR has been dragging on for a while now. I agree that the current approach is too complex and the scope of the PR has grown quite a bit from my original submission.

Unfortunately a copy constructor wouldn't be sufficient for my use case. My original requirement (which I should've maybe mentioned to avoid the XY problem) was to add a new GrantedAuthority to an OidcUser.

Since DefaultOAuth2User.authorities is unmodifiable, re-creating the OidcUser using

new DefaultOidcUser(newMappedAuthorities, originalUser.idToken, originalUser.userInfo)

and replacing the principal where it's used is the only option. However, the new DefaultOidcUser isn't an exact copy since its nameAttributeKey is IdTokenClaimNames.SUB as opposed to whatever it was for `originalUser.

[jzheaux]

Gotcha, @andreblanke, that makes sense.

Given that you need to add more authorities, could you do something like the following:

OidcUserService userService = new OidcUserService();
userService.setOidcUserMapper((request, info) -> {
	List<GrantedAuthority> authorities = request.getAccessToken().getScopes()
		.stream().map(SimpleGrantedAuthority::new).toList();
	authorities.add(your custom authority);
	return new DefaultOidcUser(authorities, request.getIdToken(), info);
});

[jzheaux]

I'm going to close this PR at this point, @andreblanke. Thanks for your efforts, and please don't hesitate to reach out if the above snippet doesn't address your concern.