OpenIdConnect: bug in Azure AD SSO Reply URL
If the reply url contains a # sign, Azure AD doesn't redirect the token back to the configured reply url but to the root.
Configured reply url: http://localhost:8050/#/login/
URL fragments in the redirect URL are not supported in OAuth 2.0 (or OpenID Connect).
The OAuth 2.0 spec (RFC 6749) Section 3.1.2, in reference to the redirection endpoint:“The redirection endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3. The endpoint URI MAY include an “application/x-www-form-urlencoded” formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component."
A second thing I notice is that you seem to be invoking the Implicit Grant flow (“response_type=id_token”, or “response_type=id_token token”), which is why the id_token (and possibly access_token) are being returned as URI fragments (“#id_token=…”) and not query string parameters (“?id_token=…”).
— Philippe Signoret
David Dascalescu commented
As you are mentioning the the OAuth 2.0 spec RFC can you please shed some light on why Microsoft chose to forbid the usage of query component on the redirection endpoint as it totally contradicts the RFC excerpt you mentioned “The endpoint URI MAY include an “application/x-www-form-urlencoded” formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters."
On one hand we cannot enter a redirect URI with ?queryComponent in the apps.dev.microsoft.com site but on the other hand Microsoft is doing a strict match and yields the error
<<The reply address 'https://raven.museglobal.ro/ssoRWP2/callback?client_name=AzureADClientTestMSSSO'; does not match the reply addresses configured for the application: '82a7d68d-41bb-4c2b-91a8-69d07f5daf62'. More details: not specified>>
It is vital for our application to use the query part because it is a multi tenant, multi authentication schemes, so it can be using Google OAuth as well and any other OAuth compliant provider so we need to distinguish between these. We had not had issues with any other OAuth2 provider.
At least do a permissive match on the query part if one cannot be defined and update your documentation on this limit.