New OAuth 2.0 authorization URL

April Purino

Hi there,

Our application works with these URLs. We can successfully generate a new token.

OAuth 2.0 Authorization Endpoint: https://preview.oauth2.sky.blackbaud.com/authorization

OAuth 2.0 Token Endpoint: https://preview.oauth2.sky.blackbaud.com/token

I have a clarification with the new URL

"New OAuth 2.0 authorization URL

For a SKY application to access SKY API, a Blackbaud user in a Blackbaud environment must grant the application access. As our documentation states, applications begin this interaction by sending users to https://oauth2.sky.blackbaud.com/authorization. While this URL will be supported going forward and we expect most applications to continue to use this URL, starting Thursday, April 28th, 2022, this URL will redirect to https://app.blackbaud.com/oauth/authorize.

For nearly all applications, this redirect will not be a concern. However, we are aware that some client-side frameworks require explicit declarations of URLs and whether the application should follow redirects. We want those applications affected to be ready for our change."

On April 28th, it will automatically redirect this URL https://oauth2.sky.blackbaud.com to https://app.blackbaud.com/oauth/authorize?

Do we need to change this URL and is there anything that we need to do on April 28th?

Authorization	https://oauth2.sky.blackbaud.com/authorization
Token	https://oauth2.sky.blackbaud.com/token

Thanks

Michael Panagos

How I've read this is:

• If you have successfully tested with the preview URLs, then the change to only the newer ciphers and disabling weak cipher suites on April 28 should not cause an issue. I wouldn't stay on the preview URL in production.
• I have been watching for any updates on the documentation, but it still uses the https://oauth2.sky.blackbaud.com/authorization URL. I think, for now, it is unnecessary to change any of your application configs to point to the new URL, but it may be smart going forward to use https://app.blackbaud.com/oauth/authorize in new applications since the old URL will be forwarding to that one anyway. I'm actually waiting to see if Blackbaud has a recommendation for which one to use going forward.
• I would test that your applications can reach https://app.blackbaud.com/oauth/authorize through your firewall before April 28.
• I have not heard anything about needing to change the token URL.

Hopefully Blackbaud can clarify anything I'm assuming that is incorrect and which authorization URL is best to use going forward.

Steven Cinquegrana

I'm a bit confused by this in regards to the token URL.

If there's supposedly no change to it, why is there a preview URL?

Also, is this/are these new URL(s) operational now? As in, can we alter our code to use them today? Or are they only functional once the redirects are established on April 28?

Thanks.

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

Chris Rodgers

Hi April,

Michael pretty well covered it. If your application is successful testing against the "preview" Authorization and Token endpoints, you're ready for the redirect and cipher suite changes on April 28th. There is nothing more you need to do. Your application will automatically redirect from https://oauth2.sky.blackbaud.com/authorization to https://app.blackbaud.com/oauth/authorize after the 28th. Your application does not need to opt into the redirect. We noted the redirect in our announcement so applications could ensure compatibility with the change (UI Frameworks, Firewalls, etc...), not necessarily to encourage you to update your URLs.

If you are done testing your application, please return your application to using the currently documented OAuth 2.0 URLs (https://oauth2.sky.blackbaud.com). The "preview" URLs are only intended for testing this change and are temporary.

Michael, as noted in the announcement, we expect nearly all applications to continue to use https://oauth2.sky.blackbaud.com/authorization for Authorization. We will update the documentation on the 28th to indicate the redirect, but the current URL will still be encouraged. If we ever have a reason in the future to serve the Authorization page from another URL, https://oauth2.sky.blackbaud.com/authorization will redirect as needed. Although we would announce such a change with plenty of notice, we may not choose to redirect https://app.blackbaud.com/oauth/authorize to the new URL for as long/"forever". That stated, developers can still choose to use https://app.blackbaud.com/oauth/authorize if they have technical reasons to or if they have particular concerns over the redirect. We won't prevent this.

Steve, the preview URL is provided for the Token endpoint so applications can verify their cipher suite compatibility. As mentioned in the announcement, the preview URLs are live now and should only be used for testing purposes. They will serve no purpose after April 28th, and they will not be supported after May 15th.

Warren Sherliker

Agree it is a bit confusing.

Read the blog about this and they refer to Cipher sets. Not sure we set Cipher sets anywhere explicitly, they are just inherited from the OS/code base, but had an email from Blackbaud saying they had records showing we were using old ones somewhere. Given how many apps and integrations we have it is not particularly helpful to say ‘somewhere’ TBH.

As far as we see if we do nothing then most if not all solutions should keep functioning as BB have redirects from the old OAuth URLs to the new ones. The cipher sets may be a complication we have to deal with if we see issues.

Steven Cinquegrana

So, @Chris Rodgers you're recommending that we don't change the auth URL and just let your end perform a redirect that you might change in the future?

@Warren Sherliker as far as I know, you're correct; the cipher suites are not part of any app but determined by the OS. I dug into this a while back and, though you could build some level of checking/notification into an app, the overhead was fairly high and ROI low.

Chris Rodgers

Right, Steve. I would recommend that you leave your Authorization URL the same unless your application has a particular technical reason to require bypassing the redirect.

Also correct that applications typically don't specify a set of cipher suites to use. And as you say, you usually don't want to/shouldn't--your application should use the strongest cipher suite available for the connection as determined by your hosting environment. We announce these changes because developers may need to update their hosting configurations to support the stronger cipher requirement. For example, Windows Server 2012 R2 requires “update 2919355" to enable TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. Also, many PaaS offerings allow for management of the suites that are enabled.

Steven Cinquegrana

Thanks Chris.

David Zeidman

If you host your own apps on your own server then you may need to look at the Cipher Suites available on that server.

This is quite a good article that explains it:

https://www.howtogeek.com/221080/how-to-update-your-windows-server-cipher-suite-for-better-security/