Unexpected behavior testing new OAuth 2.0 authorization endpoint preview.

Tatia Zuloaga

Hi there!

We are testing our integration with the preview authorization endpoint (https://preview.oauth2.sky.blackbaud.com/authorization).

We start redirecting the user to: https://preview.oauth2.sky.blackbaud.com/authorization?client_id=6ce25cc3-3d0d-409a-af39-514c42e67ec8&response_type=code&redirect_uri=https://app.livealumni.com:4444/login?handler=SignInWithBlackbaud&state=39f00827-f582-4b39-8cbf-45ef0b53d0c1

Then we can track that the users gets redirected to: https://app.blackbaud.com/oauth/authorize?client_id=6ce25cc3-3d0d-409a-af39-514c42e67ec8&response_type=code&redirect_uri=https://app.livealumni.com:4444/login?handler=SignInWithBlackbaud&state=39f00827-f582-4b39-8cbf-45ef0b53d0c1

So far this is good. But when the page loads on the browser the URL looks like this: https://app.blackbaud.com/oauth/authorize?client_id=6ce25cc3-3d0d-409a-af39-514c42e67ec8&response_type=code&redirect_uri=https://app.livealumni.com:4444/login

As you can see, it cuts the redirect URL, it removes the query parameter that is needed in our side. This also causes an error on the redirect URL validation performed by RENXT:

We believe this is an issue with the preview authorization endpoint, because in our production environment we use the same redirect URL and it works perfectly.

Chris Rodgers

Thank you for reporting this, Tatia.

I see the issue here, and I'll see if my team can support redirect URIs without the need to URL Encode their query strings within the redirect URI. For what it's worth, URL encoding the redirect URI will offer the most protection from changes in the future that could result in us misinterpreting the query string. For example, if your query string contained two parameters, we would interpret that second parameter as part of the `oauth/authorization` request and not of your redirect URI--just like we do the `state` parameter that follows your redirect URI now. That stated, we definitely want to maintain compatibility with our previous behavior if we can; we wouldn't want developers and applications to modify their applications if we can help it.

We'll look into this, and we do appreciate you testing your application early against these changes and reporting the incompatibility. We'll also review the redirect URIs for all SKY applications to see if they could be impacted by this. We'll be in touch soon.

In the meantime, you (and anyone else reading this who could be affected) can ensure support for your application now and going forward by URL Encoding the redirect URI for the /authorization request.

e.g. https%3a%2f%2fapp.livealumni.com%3a4444%2flogin%3fhandler%3dSignInWithBlackbaud

The redirect URI in your /token request should remain unencoded.

Chris Rodgers

We have reviewed the issue and made updates to address a few unintended compatibility changes regarding the handling of parameters (including `redirect_uri`) whether they be encoded or not.

Tatia, thank you again for testing your application early against these changes and for bringing the issue to our attention. Please let us know if you encounter anything else.