Solved: Validating both client id and secret - Page 2

mytre4411 · 03-28-2016 07:23 AM

As per this exercise in academy certification,it says

2.Ensure that both the app key and secret is validated before validating the user credentials.

Kindly help me how to do both appkey and secret validation before user credentials in password grant oauth type.

Should I use verify api key to validate first client id and subsequently use another policy to validate client key alone?

And then I use Service callout to Baas user store to validate user credentials.

And finally Generate Access token OAuth2 policy.

Please suggest.

Report Inappropriate Content

I figured I better chime in on this because there is a good pattern to use in this particular case.

First thing lets outline the problem.

I have an token API that has a third leg and i want to validate that the client credentials are A.)Valid and B.)Have access to this endpoint, before calling my IDP to verify the use credentials.

Now for the solution

Request Flow

You have two options here, I think someone mentioned using API Key Validation, then using a RaiseFault policy afterwards if the client_secrets don't match. This works!!

but if your not wanting the extra policy (i.e. raisefault) there is another way

Using the oathv2 policy there is a little known feature called StoreToken

When set to false you tell your oauth policy to not store the token your generating in TokenStore.

So in the request flow you can have your normal oauth policy with this StoreToken tag set to false and what will happen is that the oauth policy will generate an accessToken and refreshToken that you can use later, it also verifies the validity and accessibility of the credentials and will throw the same errors as you would with any other grant type. (life made easy)

In this configuration your target Url would point to your idp...

on a successful response ...

You would add another oauthV2 policy this one would use the ExternalAccessToken and ExternalRefreshToken tags. These tags allow you to use variables to set the accessToken and RefreshToken, the variables you would use are the ones generated in the first oauthv2 policy. You also have a chance to store any metadata from the idp with the token at this point.

View solution in original post