You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Until now the OAuth2 "Backend Application (Client Credentials)" flow
always requested the token in one fixed way: an HTTP POST where the
client id and secret were turned into an HTTP Basic Authorization header
(this is what oauthlib does by default). Providers that deviate from
that could not be used.
Two configuration options are added to the webservice backend so those
providers can be supported through configuration only:
- Token Request Method: POST (default) or GET, for providers that expose
the token endpoint as a GET.
- Client Authentication: how the client credentials are presented to the
token endpoint:
* Client ID & Secret (HTTP Basic) (default): the previous behavior,
unchanged.
* Custom Authorization header: a static, verbatim header value (for
example "SSWS <token>"). In this case the Client ID / Client Secret
fields are not used; the header name and value are configured
directly instead.
The defaults keep the exact same behavior as before, so existing
backends are not affected. The custom header is injected through a small
requests auth handler so that oauthlib does not overwrite it with its
automatic Basic Authorization header.
Two validation rules make sure the right fields are filled in depending
on the chosen client authentication: the client id and secret for the
HTTP Basic method, or the header name and value for the custom header
method.
0 commit comments