Consider adding an IssuerRegistration

[rwinch]

Summary

Central to the client code is a ClientRegistration which contains the meta information for a client to interact with authorization servers. Similarly, I think something like an IssuerRegistration would be beneficial to the resource server side.

I don't have a timeline on this issue yet and am not convinced we need or should do this. I am just wanting to get this issue logged so we don't forget and can discuss.

I'm not sure I like the name because issuers are used by clients too, so we may need to work on the name, but I'm using IssuerRegistration as a placeholder for now.

[jzheaux]

Was thinking about this too, and actually had an IssuerRegistration object at one point locally, trying to see how this might be modeled.

I think Keycloak has an interesting way to think about it, and that is as a realm. A realm, in Keycloak, maps to a set of OAuth2 endpoints--JWK Set, Token, etc.--a set of clients, users, and roles, etc. in order to support a multi-tenant Keycloak deployment.

It provides a clear mapping to what realm to send back in error messages on the resource server side.

Long story short, another name might be RealmRegistration. We could infer realm name from it as well as issuer endpoints.

[jgrandja]

@jzheaux Can you provide a link to the Keycloak class. I'm curious how it's structured.

[jzheaux]

Oh, sorry, I'm speaking about how the Keycloak AS is structured.

I do have a link to their resource-server multi-tenancy support [1], though to be clear, that isn't what I was referring to above. Still, this link is related to the larger conversation, though.

[1] - https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth-example/blob/feature/mulit-tenancy/src/main/java/demo/SpringBoot2App.java