Refused to display 'https://oauth2.sky.blackbaud.com/...' in a frame because it set 'X-Frame-Options' to 'deny'

Matthew Shepherd

I'm trying to piece together a POC for a client. I've got my app created, all my keys in the right spots, callbacks and add in registered. I am able to execute the auth flow all the way thru and view test constituent data following the C# .NET Core example app (https://developer.blackbaud.com/skyapi/docs/authorization/auth-code-flow/code-samples). I was able to render the add in inside of a tile in the Constituent Tile Dashboard however I get the following error after clicking the login button: Refused to display 'https://oauth2.sky.blackbaud.com/authorization?client_id=&response_type=code&redirect_uri=' in a frame because it set 'X-Frame-Options' to 'deny'. 

I'm obviously missing something to allow the authorization flow to occur via my add in, but I haven't been able to find any relevant discussions or examples.

Any assistance would be greatly appreciated.

Ben Lambert

Hi Matthew,


For security reasons, we do not allow the OAuth consent page (or the Blackbaud ID sign-in form) to be rendered n an iframe.  If your add-in doesn't already have an access token for the current user, you'll need to initiate the OAuth process in a separate window.  You can launch the window from your add-in, and then watch for it to be closed (and your redirect URI page can include a button on the page to close the current window, or include script that closes the current window)..  Once the window is closed, you can load your tile (pulling the access token from your backend).


More info here:
https://developer.blackbaud.com/skyapi/docs/addins/concepts/connect-to-skyapi#protection-against-clickjacking
https://developer.blackbaud.com/skyapi/docs/addins/howto-guides/addin-design/authentication#popup-dialog


Fair point about not finding any good examples - we'll work on publishing a demo of this technique.

Matthew Shepherd

Thanks Ben!


I figured it was a security issue but thought the process was to authorize inside the addin to avoid confusion by the user. So, I kept trying different ways to make it work.


Matt

Matthew Shepherd

So, I've run into another issue with this. When I initialize the popup and go thru the manual authorization piece it opens with a different session. So, by the time the user authorizes access and closes the popup the tokens are lost to the main application and my add-in. There isn't any indication in the tutorials that this is supposed to happen. I'm working around it by persisting the tokens to a db and fetching them from there on reload, but I'm still curious as to what I'm doing wrong in the first place.


Matt

 

Scott BatzEdge

@Matthew Shepherd
I'm aware this thread is a few years old now, but I was wondering if anyone ever answered your question here on if this is expected functionality or not. I have just started development of an Add-In for our institution and have run into the same issue. I am just about to start working on storing the session in a local db to retrieve when needed, but none of the official documentation talks about that as the expected model.