Implement UserInfo Endpoint

[jgrandja]

This issue will deliver OpenID Connect 1.0 UserInfo Endpoint.

Related gh-53

[idosal]

Hey, I'd love to take this when it opens up.

[jgrandja]

Thanks for your interest @idosal.

Please ping me towards end of January as a reminder.
We'll likely start the work on this at that time.
Thanks!

[amit-github-personal]

Hey @jgrandja , let me know when you're going to start working on OPENID Connect. I also want to work when it opens up

[idosal]

@jgrandja Still waiting on this. :)

[jgrandja]

Thanks for the offer @amit-github-personal . Work has already started on OIDC with #53 being merged last month.

As well, @idosal reached out last month and is interested in taking on this feature. Please stay tuned for upcoming features as they open up. It looks like features planned for 0.1.1 have all been assigned.

@idosal I'm planning on focusing on 0.1.1 feature development after I get 0.1.0 out on Feb 11. The UserInfo endpoint is scheduled for 0.1.1, so please go ahead and review the spec to gain an understanding of the requirements. Let me know if you have any questions.

[idosal]

@jgrandja Thanks, I'll get on it.

[idosal]

Hey @jgrandja, after reviewing the spec I started playing around with the code. I have a few questions I'd like to clear up:

1. Where should I get the claims? Is it implemented elsewhere, or is it a part of this task?
2. I'm unclear about this passage: If the UserInfo Response is signed and/or encrypted, then the Claims are returned in a JWT and the content-type MUST be application/jwt. The response MAY be encrypted without also being signed. If both signing and encryption are requested, the response MUST be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. How should I handle this scenario?

[jgrandja]

@idosal

Where should I get the claims? Is it implemented elsewhere, or is it a part of this task?

It is part of this task. The "source" for the claims will come from the attributes in the Resource Owner's Authentication, specifically Authentication.getPrincipal(). Given that Authentication.getPrincipal() could be different types of Principal objects, this will need to be configurable and the application would need to supply the "Mapper" instance.

For example, let's assume the configuration of a specific Authorization Server deployment authenticates users against an LDAP directory. During the authentication process, it will authenticate the user and upon successful authentication it will set the SecurityContext with the Principal model -> LdapAuthentication.LdapUser (hypothetically). The LdapUser instance would be obtain via currentAuthentication.getPrincipal() (the "source"), and then the attributes within would need to be mapped to the standard claims defined in OidcUserInfo. As mentioned above, we need this "Mapper" to be confgurable because it will be different depending on the Authentication scheme being used and supported by the Authorization Server deployment.

Does this make sense?

FYI, there are a few different ways the client can request claims. For this initial iteration, we will need to support "5.4. Requesting Claims using Scope Values" (defined in OidcScopes).

Regarding your 2nd point, we will not support JWS, JWE or Nested JWS within JWE for the UserInfo response. We'll keep it simple for the initial iteration, which is to return a application/json response.

[Scarange]

any update on this?

[idosal]

@Benzenes I'm on it. I was a little delayed due to personal circumstances, but I'll open a draft in the next few days.

[jgrandja]

@idosal How are things coming along? Were you able to make any progress?

[idosal]

@idosal How are things coming along? Were you able to make any progress?

Hey,
I opened draft #303 to see if I'm on the right track. I apologize it's been longer than anticipated, but once I have your guidance I'll get this done ASAP. Thanks!

[deejonz]

will this userinfo endpoint return the user authorities as well? i.e. roles
I tried the snapshot and I don't see them in the response

[sjohnr]

@deejonz, work on this endpoint has not been merged to main yet. In the PR, authorities would not be returned by default. However, the PR currently exposes a customization hook allowing you to provide your own mapper in which you could add anything you wish to the endpoint's response.

[deejonz]

@sjohnr Hi, do you mean the userInfoMapper? Otherwise can you point me to this hook you're talking about? Thanks.

[sjohnr]

@deejonz, yes, that's the one.

[deejonz]

thanks @sjohnr can you please give me an example how to call it? I really don't find a way.

[sjohnr]

Hi @deejonz,

This test demonstrates it. Perhaps you're asking how to use the configurer? You can check out numerous tests in this package to see some general examples of the OAuth2AuthorizationServerConfigurer in action. Does that help? If not, we'll be working on some documentation in the next few releases as well.

[deejonz]

Hi @sjohnr, it wasn't very straightforward but I managed to implement it, thanks a lot for your help!

[deejonz]

Hi @sjohnr sorry another question, why don't you leave OidcUserInfoClaimsMapper free to be extended for this purpose?

[sjohnr]

Thanks for your interest, @deejonz. There are several reasons, but the primary reason is that we always start with implementations that are closed, and slowly open up things that make sense to once APIs stabilize.

If you have a specific use case you're trying to achieve with the User Info Endpoint, let's wait until we get this merged, and you can open an issue with a description of that use case and why you feel this is needed. We can then discuss it and alternatives. Does that sound ok?

[deejonz]

yes, that sounds ok. Thanks @sjohnr