SuperOffice provider: UserInfo endpoint doesn't support multiple subdomains

[SuperOfficeDevNet]

Describe the bug

Today, the provider expects the UserInfo endpoint data will come from one environmental subdomain, i.e.:

development: https://sod.superoffice.com
stage: https://quonline.superoffice.com.
production: https://online.superoffice.com.

SuperOffice CRM Online has introduced an API cluster that will publish API calls on different subdomains, i.e.:

https://sod.superoffice.com/
https://sod1.superoffice.com/
https://sod2.superoffice.com/

This affects how the UserInfo endpoint resolves and obtains profile-related details. The authorize and token endpoints are not affected.

A PR to fix this issue is in place.

[kevinchalet]

SuperOffice CRM Online has introduced an API cluster that will publish API calls on different subdomains, i.e.:

https://sod.superoffice.com/ https://sod1.superoffice.com/ https://sod2.superoffice.com/

This affects how the UserInfo endpoint resolves and obtains profile-related details. The authorize and token endpoints are not affected.

Out of curiosity, why not adopting a more traditional approach with a single address and a reverse proxy setup doing that transparently? It's certainly something we can work around in the aspnet-contrib provider, but this clearly hurts interoperability (e.g the userinfo endpoint can't returned as part of the discovery document).

[SuperOfficeDevNet]

@kevinchalet Fair question, and it's simply legacy. Our OAuth/OIDC project began without prior knowledge of projects like openiddict and Identity Server. We are now adopting Duende Identity Server, so it shouldn't be too long before I revisit this again and use the more traditional approach.

[kevinchalet]

Haha, it's a good reason 🤣

We are now adopting Duende Identity Server, so it shouldn't be too long before I revisit this again and use the more traditional approach.

In this case, should we wait until you figure out what the final design will be, in case it would change again?

[SuperOfficeDevNet]

In this case, should we wait until you figure out what the final design will be, in case it would change again?

It's not an easy 'swap and replace' job, so it may take months before we have completed retrofitting Duende Identity Server.

[SuperOfficeDevNet]

Request to reopen this issue... PR to follow.

[martincostello]

Fixed in #756.

[martincostello]

Thanks for you contribution - this fix is now available in the 6.0.15 and 7.0.1 releases.