1

I have an Azure API Management (APIM) (Basic) service set up to authenticate my JWT tokens over HTTP query connections via the validate-jwt plugin, and that works fine. I would like to do the same JWT token validation using a WebSocket connection over APIM.

The best I can get with websockets is the typical subscription-key querystring validation. After reading that WebSocket clients (like Apollo's WebSocketLink) only allow query string params as opposed to header modifications (potential due to Browser restrictions?), I tried passing an "authorization" query string pair in, but validate-jwt seems to misread that too (the websocket connection fails).

Microsoft does appear to advertise JWT validation on the docs website (https://learn.microsoft.com/en-us/azure/api-management/websocket-api) but I can't find a clear example to show how that's expected to work.

Any suggestions (especially if you've gotten this to work)? Thanks!

BarryM
  • 176
  • 9

1 Answers1

0

You can use it as below in the handshake operation but once the handshake is done the http request is upgraded to WebSocket so the operation is no longer executed during the web socket connection.

https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#ValidateJWT

Mo Haidar
  • 3,748
  • 6
  • 37
  • 76
  • thank you for the answer, but I would appreciate if you could be more specific - should the policy be able to be applied in the Inbound processing of the onHandshake method? I'm not quite clear from the docs if I'm applying the policy at the wrong level. I'm fine if the validation is only done on the initial connection, but I'm not clear if it is being done at all. Again if there's an example of this working somewhere I'd appreciate it. Also is it fair to assume that this should be validated using the ws querystring pair or is there another way? – BarryM Mar 05 '22 at 02:20
  • Actually same doc provides multiple examples and also explain that this policy should be used in the inbound section at any scope (Global, API, Operation or product scope). The policy will look at the header that holds the token to read and validate it, you tell the policy which header is that using the header-name attribute. https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#examples – Mo Haidar Mar 06 '22 at 12:05
  • I appreciate the doc says this, but when I create a websocket api thru the portal, the only option I get to add policies on is at the onHandshake policy, and there’s no flexibility to add this at the API level (which you get with http api’s). If you’ve actually gotten this to work, I’d appreciate a screenshot of how your APIM setup looks with the policy applied. Alternatively if you have an ARM template you can export it would equally be helpful. Thanks again for your response. – BarryM Mar 07 '22 at 15:29
  • For websocket APIs policies are only supported inside onHandshake operation. That operation policy is executed only during initial connection request, not for every WebSocket message processed. Adding validate-jwt policy there is fine and expected to work, but as Mohamad has mentioned this policy will be executed only once for every WebSocket connection. – Vitaliy Kurokhtin Mar 08 '22 at 03:30
  • Isn't the problem that a client opening a websocket cannot set a header to include the token? – DDD Mar 07 '23 at 16:37
  • @DDD I think you're right - I've moved on from this problem ages ago (and away from APIM in general) but it's likely very much related to that. – BarryM Jun 02 '23 at 14:29