Hi,
I’m working on a pilot project where token is issued from identifyserver3 (can’t attach link) hosted locally. The backend system uses username and password to login. Token issued without problem using postman by specifying grant_type=password.
However I’m not able to get it works when setting up HTTPRequest’s OAuth2 credential. Unfortunately I can’t attach more than 1 picture being the new user.
Based on the identityserver3’s log below, I noticed Authorization flow is set to AuthorizationCode. Setting the additional request parameter with grant_type=password doesn’t work.
2020-08-17 19:55:58.4268 ERROR IdentityServer3.Core.Validation.AuthorizeRequestValidator | Invalid flow for client: AuthorizationCode
{
“ClientId”: “----client”,
“ClientName”: “----client”,
“RedirectUri”: “http://localhost:5678/rest/oauth2-credential/callback”,
“AllowedRedirectUris”: [
“http://localhost:5678/rest/oauth2-credential/callback”
],
“SubjectId”: “unknown”,
“ResponseType”: “code”,
“ResponseMode”: “query”,
“Flow”: “AuthorizationCode”,
My pilot confguration doesn’t use AuthorizationCode flow. Is it possible to expose Authorization Flow as an OAuth2 header and in order to specify a different flow/grant types?
I’m not sure is the content-type header=application/x-www-form-urlencoded is needed when grant_type=password. If needed, then I’m not sure how to specify it as there is only 1 Query Params field provided and the param (resource, username, password) are defined as Request body.
Hey @engowen, welcome to the community. If I understand well, this is not posible yet. You can change the post to a feature request. Also, I read the specification, and it seems that it is a bad practice to use that grant type. draft-ietf-oauth-security-topics-13
The resource owner password credentials grant MUST NOT be used. This
grant type insecurely exposes the credentials of the resource owner
to the client. Even if the client is benign, this results in an
increased attack surface (credentials can leak in more places than
just the AS) and users are trained to enter their credentials in
places other than the AS.
Hi, I’d moved this topic to feature request as suggested.
I intend to host n8n on a secure enterprise network that’s behind a firewall with no access to outside world. I’m trying to orchestrate the data exchange between several bespoke webAPIs and don’t want to keep authenticating each time the workflow is ran or token is expired. I know it is not recommended but most proprietary solution take ages to catch up with the new trend. Having options to set grant_type is a fallback to support legacy system. Thanks.
1 Like
Just an update, this request can be dropped as i can get a token with POST request using a grant_type=password header. The next node refer to the token as Authorization header using Bearer {{$node[GetToken].json["access_token]}}
1 Like
I am interested in doing something similar to this using grant_type=client_credentials, but when I try this I get ERROR: StatusCodeError: 400 - {“error”:“unsupported_grant_type”}
Are you able to show how you configured the header to get this to work?
I wrote a small blog on a workaround for using “client_credentials” grant type with services - Using Client Credential OAuth in n8n | by Tuckner | Feb, 2022 | Medium
