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!
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
Related
While using webhooks to get notified about channel lifecycle events in Ably Realtime, is it secure to send the access_token as part of the websocket url query params?
(disclaimer: I am a developer advocate for Ably, and posting and self-answering a commonly asked support question here on Stack Overflow so our users can find this more easily)
From a security perspective, it doesn't really matter where the access token is stored. In an ordinary HTTP request it would be stored in the header, or in a message after the websocket connection is established. However, many websockets for clients don't support client headers, and both of these are equally accessible to an attacker who can inspect traffic. Connections default to being over TLS these days, so from the outside you can't access query params, nor can you access the contents of messages.
Traditionally it was considered poor practice to have credentials in query params because URLs can get stored in places such as logs for proxies, browser history, etc. However, neither of those concerns apply to websockets (a browser won't keep history of the connections made by a page), and proxies do not have access to the URL when there is a TLS tunnel. This concern arose when non-TLS interactions were the default. For comparison, most OAuth flows result in an endpoint access being made with an access_token query param.
I tried to implement custom Authentication via a authentication endpoint in an azure mobile app. I've created an Api Controller, that creates the Jwt using Azures AppServiceLoginHandler.CreateToken method. When I post to this controller with turned off Azure App Service Authentication, I get a token, but when I want to use it later, I always receive a "401 Unauthorized".
But when I turn the setting on in the Azure Portal, and send the very same request
I get:
The requested resource does not support http method 'GET'.
I'm not changing any code, and I'm certainly using a POST request - The exact same request, that works with turned off App Service Authentication.
My Code is essentially the same as here:
https://www.newventuresoftware.com/blog/custom-authentication-with-azure-mobile-apps
Could someone enlighten me here? Do I need additional configuration somewhere?
As adrian hall's book about Custom Authentication states as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
For custom authentication, you need to turn on the Authentication / Authorization in your app service for authenticating your token. Moreover, I would recommend you leverage fiddler to capture the network traces to narrow this issue. Additionally, you need to make sure that you send the custom login request with HTTPS. Details, you could follow this similar issue.
I need to do a communication between two applications, and I want to ensure the client application identity.
I wanna know if is there some pattern to make something like this:
The client application has a key and secret
The client send some info to the main application with identity data
The main application verify the client and returns the requested data
You may want to investigate client and server TLS certificates. They will allow for a mutual authentication between the server and the client.
I think You are talking about server-client communication. In this case, you have to search RESTful API. With REST, you implement endpoint which returns your data as a JSON. So you can use the data in Desktop app,Mobile app or Web app and with this way you can resolve the security risk. Because in mobile app
or desktop app, conneting to db is risky. You cant put your db options in your app. Implement a REST which returns JSON and send a http request in client.
If response is OK. Parse the JSON and use in the client
Here is the simple example in php
I am developing a backend for a mobile application using Node.js to handle HTTPS requests. I have set up an SSL to connect from the client to the server and was wondering if this was secure enough.
I don't have experience with intercepting endpoints from the mobile devices, but I have seen that it is possible for people to monitor internet traffic out of their cellphones and pick up endpoints to server requests. I have seen hacks on tinder where people can see response JSON and even automate swipes by sending http requests to tinder's endpoints.
My real concern is that people will be able to update/read/modify data on my backend. I can implement OAuth2 into my schema as well but I still see cases in which people could abuse the system.
My main question is whether or not using HTTPS is secure enough to protect my data, or if a session authentication system is needed like OAuth2.
Thanks.
HTTPS, providing it is properly configured, will ensure the message was not read or changed en route and that the client can know the server it is talking to is not a fake.
It will secure the transport. It will not secure the application.
For example supposing you have an app that allows you to send a message saying https://www.example.com/transfermoney?from=Kyle&to=BazzaDP&amount=9999.99 and the server does just that based on those parameters. Then I could send that message myself - I've no need to intercept any app messages.
Normally the server needs authentication as well as HTTPS to, for example, verify only Kyle user can send above message and not anyone else. HTTPS normally only gives server authentication not client authentication (unless using two way certificate HTTPS).
So the question is, even if an attacker cannot read or alter any messages between app and server can they still cause harm? That is the measure of whether it is secure enough.
A SSL connection is only secure with the content you are sending.
SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL
So i would say just using the SSL encryption is save to transfer data between - i might consider OAuth2 for password etc.
But i would recommend to use GET for retrieval data and post for authorized data
You're building an armored tunnel between two open fields.
Assuming that you use current SSL protocols and settings, and valid certificates from trusted issuers, you can pretty much assume the network is OK.
However it's still entirely possible to compromise any or all of your transaction from the client. Security really depends on the device and how well it's configured and patched.
I'm working on a security setup suitable for the following client/server scenario, and I'm having a couple of questions/considerations that I'd like to share with you.
Situation:
I have a number clients on different platforms:
HTML-client (single page apps (SPAs) using jQuery/AJAX)
Android-app
Silverlight client
Windows client
Windows Mobile client
The large majority of the corresponding server components are based on .NET WCF using REST (but for some backends, I'm using other protocols).
I've found the open source project IdentityServer v2 from ThinkTecture to be a nice and flexible security token service (STS) for my solution. It supports a number of token types, protocols and is highly extendable and has a self contained Identity Provider (IdP) based on ASP.NET Membership database if needed.
The basic flow for clients using usernames/passwords is as follows:
The client makes an unauthorized HTTP call to a ressource (that requires authorized access) on its server
As the client is not yet authenticated, the server returns a HTTP 401 (unauthorized) providing an address to the STS in an HTTP Location header (see note on this below)
The client submits its credentials to the STS in a HTTP Basic Auth header
The STS returns a JWT token containing all relevant user claims
The client now repeats its initial request from step 1 including the JWT token in the HTTP Auth Bearer header
The server validates the token, as it originates from a trusted STS source, and returns the requested ressource
I know that step #2 is a bit unorthodox in combining the HTTP 401 error message with a HTTP Location header normally associated with the HTTP 3xx status codes. I need the 401 status code because of my jQuery/AJAX clients which handle the 302 redirect message automatically without any chance to interscept the redirect.
Now, the system needs to use an external IdP. The "internal" STS is customized to forward auth requests to the external IdP handling transformation of claims from the external IdP format to the internal format. One catch with this is that it implies the "password anti-pattern", but for now all systems are interal and trustworthly.
Could WS Federation be my friend?
The above basic flow applies to at all clients, browser based or not. But for specifically browser clients, I've been looking into a federated security scenario, having the resulting IdP/STS to provide a login mechanism for the clients. The STS that I use (IdentityServer) can be configured to be used in conjunction with a WS-Federation compliant STS. Thereby tokens are automatically transferred to the target token format (in my case for instance from the external STS's SAML token to the internal JWT token).
With this I can have some sort of a SSO mechanism.
Now my questions:
Is my described basic security flow optimal?
Is WS-Federation only applicable for browser clients?
If not, how can it be used with for instance my android clients?
In WS-Federation with more STSs, how is the communication flow between: client - internal STS - external STS (in terms of HTTP communication, cookies and stuff).
I don't think what you describe is WS-Fed. WS-Fed never involves 401 and never involves authentication headers.
WS-Fed has two versions, passive and active.
Passive is for browsers. It consist in 302 to the identity provider which in turn POSTs the SAML token back to the caller. The authenticaiton is then supported by cookies.
Active is for active clients (applications). It consist in a SOAP response that instructs the caller to go to the identity provider for the token. The SOAP response from the identity provider contains a token which is then supplied to the service.
What I believe is that the active scenario is quite complicated if your client doesn't support the WCF federation authentication binding (wsTrustFeb2005). You'd have to implement the flow on your own.
What I'd like to recommend instead would be the OAuth2 flow. OAuth2 has 4 different flows, of which two correspond to WS-Federation's active and passive: authorization code flow is for browser-based apps and the implicit flow is for desktop/mobile applications.
http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#authorization
OAuth2 integrates easily with WebAPI services and there is a great support for it in the DotnetOpenAuth library.
This and other authentication/authorization options are described in great detail in the Pro ASP.NET WebAPI Security book
http://www.amazon.com/Pro-ASP-NET-Web-API-Security/dp/1430257822
Even if you are not planning to build your backend around WebAPIs (but rather RESTful WCF as you mention), the book will give you necessary background on OAuth2.
On the other hand, if you still insist on WS-Federation, this free e-book describes both active and passive scenarios:
http://msdn.microsoft.com/en-us/library/ff423674.aspx