Expose Grant Type/Credential Flow for Generic Oauth2 authentication


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”: [
“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. https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.4

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]}}