OAuth2 Client Credentials: Support sending client_id and client_secret in body

[dor-denis]

1. Postman Version: 4.6.2
2. App (Chrome app or Mac app): Chrome app & Mac app
3. OS details: OS X El Capitan
4. Is the Interceptor on and enabled in the app: no
5. Did you encounter this recently, or has this bug always been there: recently, never tried before
6. Expected behaviour: Postman retrieves the token
7. Screenshots:
   https://s18.postimg.org/evzrjs0yh/Screen_Shot_2016_08_30_at_09_32_25.png
   https://s18.postimg.org/sqy228vdl/Screen_Shot_2016_08_30_at_09_32_37.png

You can see in the second screenshot that no client_id and client_credentials were sent at all

[alexfu]

I noticed this too. They are actually sent in the Authorization header. Would like to see this as an option since our server expects them in the body as form data and not in the auth header.

[aldav82]

Agreed. Using:

• Postman 4.8.3
• win32 10.0.14393 / x64
• Azure AD OAuth2 Client credentials flow.

Azure AD expects those parameters as part of the body https://docs.microsoft.com/en-us/azure/active-directory/active-directory-v2-protocols-oauth-client-creds

Postman is sending them encrypted as Basic Authorization Header, so Azure AD is returning Unauthorized response.
I think Azure platform is gaining momentum. Azure AD support should be a welcomed addition to Postman Client Credentials Authentication (Postman works OK with Authorization Code Grant)

[benc-uk]

I'm also having this issue with Postman and Azure. I can manually use Postman to request a token - then copy & paste it, but that's clumsy.
Would be great if Postman properly supported Azure AD OAuth2

[sdnts]

We're looking into a more customizable auth helper, which should help you guys out. Will keep you updated of its progress.

[aldav82]

Ok. will be much appreciated.

[neverendingqs]

Azure is implementing OAuth 2.0 wrong.

The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.

...

Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes). The parameters can only
be transmitted in the request-body and MUST NOT be included in the
request URI.

https://tools.ietf.org/html/rfc6749#section-2.3.1

I would file a bug with Azure. There is no reason Azure should not be respecting the OAuth 2.0 spec.

Related: #1360

[jongio]

I will ask the AAD team about this. In the meantime, you can use this approach: http://blog.jongallant.com/2017/03/azure-active-directory-access-tokens-postman/

[aldav82]

@neverendingqs I can't quite get why you say Azure is implementing it wrong. In the very same link you provided
https://tools.ietf.org/html/rfc6749#section-2.3.1

it clearly says:

Alternatively, the authorization server MAY support including the
client credentials in the request-body using the following
parameters:

  client_id         REQUIRED.  The client identifier issued to the client during
  the registration process described by Section 2.2.

  client_secret         REQUIRED.  The client secret.  The client MAY omit the
  parameter if the client secret is an empty string.

Seems to me that sending client_id and client_secret in the request body is correct, no? In your comment, you quoted a text that said is was NOT RECOMENDED but that doesn't mean it is wrong.

[neverendingqs]

@aldav82 - my take is that HTTP Basic authentication scheme must be supported, even if using the client credentials in the request body is also supported.

The "alternatively" is making me rethink though. At its natural reading, it seems to override the MUST in the previous paragraph. It's strange to use MUST instead of RECOMMENDED though if an alternate is possible...

[digitebs]

guys any idea when is this getting fix? i notice the client_id and client_secret not being passed also as body form

[harryi3t]

This is in our roadmap for Postman 5.3 (will be released around next week)
We are adding an option to specify where should the credential go (header/body)

Marking this as a feature and removing the label bug, since the credentials were not missing. They were always passed in the header.

[harryi3t]

Hi, everyone

Postman 5.3.0 is out with an extra option to configure where the client credentials should be sent.
Please choose Send client credentials in body from the dropdown

Thanks

[querylife]

I'm using Postman for Chrome version 5.5.2, OAuth2 Authorization, I do not see the "Client Authentication" drop-down in the "Get New Access Token" dialog box. Instead, I see the following fields in the dialog box: Callback URL, Token Name, Auth URL, Access Token URL, Client ID, Client Secret, Scope, Grant Type and a checkbox for "Request access token locally". Is there another way of specifying to send client credentials in body, other than from this dialog box? Why is the option missing? Thanks. Pat B.

[harryi3t]

@querylife This is available only on our native apps. You can download them from https://www.getpostman.com/apps