Closed endstreet closed 1 year ago
I think you could do this, but for code based extensions we'd be expecting that rather than looking to override BuildPayload
on the concrete class you would register your own implementation of IAuthorizationPayloadBuilder
(the interface that defines this method).
It looks though that you are looking to implement OAuth Client Secret Authentication, so perhaps we can consider this as another configuration based option for authenticating with services. Do you have a particular SaaS service you are looking to integrate with that uses this method?
Thanks Andy, Indeed we are implementing OAuth Client Secret Authentication. In our case it is not a publicly available SAAS service but the implementation of a large international group.
@endstreet Were you able to implement something that lets you authenticate?
I was hoping to use the package with the Client Credentials Grant flow that we use for our own APIs.
Client credentials grant flow is something we've worked on, but we haven't released and documented it yet. So it won't work with the current version of the package I'm afraid. Look out for an update in the upcoming weeks though.
We'll have support for client credentials grant flow with the next release of the package, due next Tuesday.
Hi awesome plugin.
I am adding this in response to you inviting enabling other services for your plugin. I enthusiastically installed the package for the obvious obfuscation of the Authorization methods.
I hit a snag when trying to do the first step of Authorizing the first defined service.
The BuildPayload() method is in a sealed class and uses a standard random no.
Our implication does something slightly different for additional security: e.g. : The Authorization header for the authorize call is not using a radnom number but rather:
Being able to override this method will expand the amount of services you will be able to service exponentially.
It is offered as a suggestion rather than a bug.