Can Authorization be done using api calls only, and not involve the user's browser?

Hi @Brian Gaski

For some quick background - SKY APIs operate in the context of a user identity in order to allow our customers to control the surface area of what the user identity can see/do (because customers, not Blackbaud, define security roles and permissions for users). That identity can be a human user, or a service account created explicitly for the purpose of the integration. In either case, we treat the consenting identity as the source of the truth for the permissions we enforce.

To address the server to server use case, we have a headless/unattended sample on github that can make API requests without having to get an OAuth token via the typical interactive UI prompt. A server to server app can make calls as long as there is a one-time UI prompt typically done in some sort of setup or config experience for an integration. After that one-time OAuth interactive prompt, the integration would store the refresh token securely and there would be no need for any additional user interaction. This process is also described in this community post and is one approach to achieve this use case.

Another option to be aware of is the use of a tool like Postman to go through the initial OAuth flow to get an access token (and refresh token). Postman can be configured to essentially "impersonate" the OAuth application (client ID/secret) for the purposes of acquiring the initial token. This only works if the developer is also an application user. There are several community posts about this approach too, such as this or this.

Hope this helps, let us know if you have any other questions.

Thanks.

@Mina Mistry

Is this the only server-to-server solution? It feels like there is a lot of room for failure to store the refresh token in json. This feels like a cheap workaround.

I'm a bit shocked that this is the only solution.

@Alex Wong
Hey Alex! Appreciate the response. I think this solution feels like forcing a square peg in a round hole. Yes, I've used and built RESTful APIs that use this `authorization_code` flow. However, that was for scenarios where there was a UI and the API was there for data retrieval to support the UI.

The scenario being described is a machine-to-machine scenario. OAuth2 has support for this scenario. It's called the `client_credentials` flow. It appears that the Sky API does not support this flow. That's very disappointing, and I'd say it feels rather short sighted. Maybe not for all of the Sky API, but for Merchant Services, which is a payment processor, only supporting `authorization_code` feels like a miss. I'm curious if there are plans to add support for the `client_credentials` flow?

@Nick Trentacoste @Alex Wong we don't currently have plans to support the OAuth 2.0 client credentials grant type in SKY API.

While the authorization code flow isn't ideal for your scenario, we know that there are a lot of developers who have been successful using it with the Payments API using the headless data sync example. We also extended the lifespan of refresh tokens and introduced the ability to preserve the refresh token value so that it can be used across multiple independent threads.

Having said that, I'm always interested in how we can make things easier without compromising security,

@Nick Trentacoste Up until April last year, SKY API supported implicit flow in addition to authorization code flow. However, we deprecated implicit flow (now considered legacy) and introduced PKCE as a more secure method for public clients. Blackbaud products have a security model based on user permissions which works well for user interactive authorization.

Our supported grant types have met our requirements so far, for all SKY APIs. I understand it's not ideal for scenarios where users aren't involved, but Payments API developers have been able to workaround it and still be successful. That's why it hasn't been a priority to introduce support for other grant types. However, we'll continue to evaluate OAuth 2.0 grant types and make improvements like how we introduced PKCE last year.