0

My api is protected by 2 means: JWT validation and Ocp-Apim-Subscription-Key requirement.

The Azure AADB2C JWT asserts that the user is who he says he is while guaranteeing that he proved such identity (user+password) recently.

The Ocp-Apim-Subscription-Key proves that A user subscribed to the referred api/product.

The problem is: how can I assert that the Ocp-Apim-Subscription-Key being provided belongs to the user informed by the JWT? What if the "hacker" was able to steal a credential from partner A and steal a Ocp-Apim-Subscription-Key from partner B?

EDIT 1 - Here is what I did:

  1. Created 2 accounts A and B
  2. Created a api that requires OCP key and validates JWT
  3. Created a product P for that API
  4. Subscribed A to P
  5. Got a JWT using B's credential
  6. B "stole" A's subscription Key
  7. B successfully consumed product P using his own JWT and A's subscription key
Leonardo
  • 10,737
  • 10
  • 62
  • 155
  • actually no... still looking for solutions/workaround – Leonardo Nov 25 '21 at 12:22
  • 1
    @DeepDave-MT I posted this on microsoft QA: https://learn.microsoft.com/en-us/answers/questions/641069/azure-api-management-verify-that-jwt-and-ocp-apim.html – Leonardo Nov 25 '21 at 14:12

2 Answers2

0

I think you're mixing the ideas. Client A and Client B should not share the same Ocp-Apim-Subscription-Key. The first validation should be to check if the provided username and password are correct. (authentication part).

Assuming it's correct, you need to check the authorization part. If they are providing the right Ocp-Apim-Subscription-Key value for the product they're assigned.

E.g.

username | password | Product Subscription | Product Key
abc      | 123      | A                    | 62140881-0e72-4d99-b26c-802423a815f5
def      | 444      | B                    | 5f175bb2-f4ec-4302-ac27-56dab358b04b

let's say user def is trying to use 62140881-0e72-4d99-b26c-802423a815f5 as the product key, even then it's a valid one, they should receive a 403 error.

Thiago Custodio
  • 17,332
  • 6
  • 45
  • 90
  • pls check my edit. A and B don't "share" any kind of credentials, but rather one stole the info from another, by any means. – Leonardo Nov 09 '21 at 17:58
  • I think that having a Ocp-Sub-Key at hand only proves that someone, at a unknown point in time, subscribed to that API/Product – Leonardo Nov 09 '21 at 22:47
  • Correct. But unless you somehow know the ip-range and do some kind of fingerprinting, there's nothing you can do. For Example, if you somehow use my username and password and try to login on Facebook, it will detect it's an unknown device. But if we both use iphone and live near by, I believe it will work. The same for you application, unless you somehow correlate A users, if someone from B uses valid credentials from A + B subscription it also will work. But, you can try to flag/alert when that happens, A user logged using B credentials. – Thiago Custodio Nov 10 '21 at 14:26
  • but the thing is that the subscription, on the portal, will/should be assigned to the same user authenticated on the access token... this looks like a security hole – Leonardo Nov 10 '21 at 16:09
  • 1
    I would need to make a test, but I believe this scenario should be covered by APIM. In the last case, you can validate yourself if the user had subscribed to the product. (https://learn.microsoft.com/en-us/rest/api/apimanagement/2021-01-01-preview/user-subscription/get) – Thiago Custodio Nov 10 '21 at 16:25
0

When using a subscription key for a user, context.User is populated which has details like the email address which you can use to validate against a similar claim present in the JWT token. You would use the choose policy to act accordingly if they match or don't. You can short circuit the request by using the return-response policy inside the choose policy.

Leonardo
  • 10,737
  • 10
  • 62
  • 155