Support headless auth using security tokens
As a developer, I want to create daemons/services that can perform unattended authentication in an industry-standard way.
Currently, the lack of headless authentication requires workarounds that diverge from industry best practices.
-
Background
Blackbaud currently doesn't support headless API authentication. The reason given is that auth should happen in the context of a user: https://community.blackbaud.com/forums/viewtopic/426/36487?post_id=137419#p137419
As a workaround, the developer can run a utility app to retrieve an initial token and refresh token. The refresh token can be stored and used to obtain tokens in the future.
-
Issue
Is a nonstandard use of authorization code grant flow.
Requires a data store.
Violates the principle of least surprise.
Is unnecessary for running in a user context.
-
Proposal
Enable a truly noninteractive flow like resource owner password credentials, but require users to append security tokens to their passwords in token requests.
Salesforce does this for connected apps. The user generates a security token in their profile settings, then appends it to their password when authenticating in a connected app.
-
PowerShell example
Invoke-RestMethod 'https://login.salesforce.com/services/oauth2/token' -Method Post -Body 'grant_type=password&username=<MyUsername>&password=<MyPassword><MySecurityToken>&client_id=<MyClientId>&client_secret=<MyClientSecret>' -ContentType 'application/x-www-form-urlencoded'
-
Guest
- Oct 6 2020
Related ideas
Just saw this. Any (secure) option that doesn't require manual auth would be a a huge step forward, I think. I have no problem with HTTP Basic Auth either (which is used to obtain initial auth tokens anyway).
Yes, please! We don't like the idea of our payment processing going down just because there was an error (either in our code, or network down time) when we get a new refresh token. Headless auth would fix this, or something like allowing the previous 5 refresh tokens to be used so we can retry when there is a failure. Currently if there is a failure it requires a manual step to re-authenticate, which causes downtime (meaning payments can't be accepted etc). And that isn't really an acceptable option.