Failure when trying to login into Azure using this "Retrieve Oauth2 Token" assertion as with "Resource Owner Password Credentials" option, client_secret is mandatory whereas Azure don't ask for this one and even fails if we provide it.

How can we prevent this ?

Philippe,

Instead of using the  Retrieve Oauth2 Token can use the Route via HTTP(S) assertion post the base64 encoded credentials and set the Response Destination: <context_variable>.

To extract the token from the response use the Evaluate JSON Path Expression from the <context_vairable> to parse out the token information.

Hi,

you mean like this.

This is indeed what we used to do but what we wanted is to use some more advanced technique by using an integrated assertion instead of doing it the old fashioned way. The only showstopper using "Retrieve Oauth2 Token" being the client_secret that, for Azure to request owner credentials, only need the... owner credentials, and client_id.

Hi @PhBrand,

Unfortunately we do not have much else by way of the client assertions for OAuth. Though the RFC does not require the client ID and secret the OTK does. I imagine for purpose of improved security as it seems to be common practice with this flow.

OAuth Request Scenarios - CA API Management OAuth Toolkit - 3.5 - CA Technologies Documentation 

Perhaps you can use your policy as an encapsulated assertion:

Encapsulated Assertions - CA API Gateway - 9.2 - CA Technologies Documentation 

Regards,

Joe

Perhaps initiating a Request for Change so that this assertion in next version allows only client_id ?

In fact our code is already implemented as an encaps, "Azure ADAL" but we somewhat wanted to reduce code size using internal assertion instead.

Absolutely, you can create an 'idea' here on the communities for this as it is how enhancement requests are now handled . 

Product management periodically reviews the ideas for inclusion in future releases. I would suggest including your use case with Azure to bring focus to the need for it.

Regards,

Joe

Hello PhBrand ,

I might not understand your issue properly.

As per my understanding, the otk assertions are more likely built for otk, ie. when otk is working as oauth server. Many otk assertions even access the otk database directly.

Different implementation of oauth may require different interfaces. I think it's normal if otk assertions cannot work with other 3rd party oauth server.  We might make changes to be compatible with Azure oauth, but what if google oauth? facebook oauth?

So, for the 3rd party oauth server, it could be better to follow their documents to call their API endpoints.

Regards,

Mark

Hi Zhijun,

As per my understanding, the otk assertions are more likely built for otk, ie. when otk is working as oauth server. Many otk assertions even access the otk database directly

I'm talking here about a client assertion, which has as per my limited knowledge nothing to do with the server part of OTK.

I don't know what reference documents were used in order to implement Oauth2 assertions on the Gateway but if I'm referring to RFC 6749, chapter 4.3 does not mention client_type/client_secret to be mandatory but only : "If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server".

Please forgive me if I'm totally wrong here.

Hi PhBrand ,

Nothing wrong with you at all.

Exactly, I maybe the one who is wrong. As I am only guessing with common senses. 

I just guess the product team built the client assertions paired with OTK endpoints only, same as the QA.

Look at the token password endpoint ( OAuth API Endpoints - CA API Management OAuth Toolkit - 3.5 - CA Technologies Documentation , this endpoint should be for "Resource Owner Password Credentials"),  the client_id and client_secret are required. So the client assertions needs to include them otherwise it will cause error. That could be an evidence of my guessing.

Just let you know my thinking on this issue, there is no right or wrong here.

Thanks,

Mark

Hello PhBrand ,

From the screenshot of your code, the client_id is in the request body for Azure endpoint.

But the "Retrieve Oauth 2.0 Token" put the client_id and secrete in header by default.

Did you try to select "Request Body" for "Authentication Scheme" option under "Client Authentication" section?

Regards,

Mark

Hi Philippe Brand

Did you have a chance to review Mark's last update?

Regards

Seenu Mathew

(Ops seems I didn't press "Save", here's my comment auto-saved)

Hi Mark,

Yes I did try using "Request Body" as I couldn't make it work using Auth Basic, even when building my own request.

About endpoint documentation, I've analyzed the OTK code and yes client_secret is mandatory also there which could be, IMHO, a mistake in actual implementation as per the "Resource owner Password Credentials" scheme.

Nevertheless I've submitted a request for enhancement, let's find out what devs think about this.

Regards,

what is the purpose of this below, could you pls provide an instance of it. I understand client send the access token?

Retrieve Oauth2 Token