Using IdSrv v3 for SignalR

[mauriciod73]

I currently have an system consisting of a webapi, web client and desktop client. At the moment they all use IdSrv 3 for authorization/authentication but now I need to include a SignalR service to handle syncing across clients. I was wondering if it's possible to use Beta1 for auth in this service.

Thanks

[brockallen]

SignalR is OWIN hosted, so it should be able to use katana authentication middleware for authentication.

[mauriciod73]

How would the token get passed, given that SignalR doesn't accept HTTP Headers? Is there a way to set up Thinktecture for getting this info from cookies? It'd be nice to see an example in the samples.
Thanks

[brockallen]

You'd have to ask the SignalR folks.

[leastprivilege]

What would be "Thinktecture" in that case (that's a company name) - and why would we "get" that - SignalR is the receiver.

[mauriciod73]

Sorry, I meant to say IdentityServer. I've been reading more about the issue and I guess that what I'm trying to ask is how would I set up IdSrv so it retrieves the access token from a cookie or a query string instead of the Authorize header, since this don't exist in the SignalR pipeline.

[leastprivilege]

IdSrv does not "retrieve" anything. It gives you a token - SignalR would be the consumer...

[ghost]

@mauriciod73 We are successfully using SignalR with access tokens generated by IdentityServer. This is in fact very easy. The access token is passed through the query string since not all SignalR transports support http headers.

In the access token plumbing code, you should specify an access token provider, which is responsible for retrieving the access token from the request.

    app.UseJsonWebToken(
            issuer: "",
            audience: "",
            signingKey: <key>,
            location: new MixedOAuthBearerAuthenticationProvider());

MixedOAuthBearerAuthenticationProvider is our own class which can retrieve tokens either from query string or from the request header:

    public class MixedOAuthBearerAuthenticationProvider : OAuthBearerAuthenticationProvider
    {
        public override Task RequestToken(OAuthRequestTokenContext context)
        {
            var token = context.Request.Headers.Get("Authorization");
            if (!string.IsNullOrEmpty(token))
            {
                token = token.Substring("Bearer ".Length);
            }
            if (string.IsNullOrEmpty(token))
            {
                token = context.Request.Query.Get("access_token");
            }
            context.Token = token;            

            return Task.FromResult<object>(null);
        }
    }

[leastprivilege]

nice!

[mauriciod73]

@dennisfrostlander Thanks!! This is exactly what I was trying to do. I'll give this a try and let you know.

Thanks!

[billpratt]

Isn't there a security risk of the access token being intercepted by passing it via query string?

[leastprivilege]

Well - just the usual ones...SSL is a pre-req of course...query strings end up in web server logs..and potentially referer headers.

[brockallen]

The OpenID Connect spec specifically states that tokens should not be passed via query string, and so our implementation errors (at least code in dev branch does) if you change response_mode to query and the request contains response_type id_token or token. In short, yes, this is a concern and the spec says don't do it and we don't.

[leastprivilege]

I assume you mean sending the token from client to resource - not from STS to client...?

The OAuth2 spec explicitly allows it (RFC6750) - but as Brock and I mentioned - there are concerns.

[mauriciod73]

In SignalR 2, the windows client allows sending headers, so there is no problem there. The problem is that most SignalR Javascript transports don't allow headers. This leaves two options, sending the token in the query string (which means the server could end up logging it), or in a cookie.

[billpratt]

My vote would be cookie

On Oct 2, 2014, at 8:35 PM, mauriciod73 [email protected] wrote:

In SignalR 2, the windows client allows sending headers, so there is no problem there. The problem is that most SignalR Javascript transports don't allow headers. This leaves two options, sending the token in the query string (which means the server could end up logging it), or in a cookie.

—
Reply to this email directly or view it on GitHub.

[leastprivilege]

So as I said in my very first post - this is not an IdentityServer problem. We return tokens via the OAuth2/OIDC protocol to the CLIENT.

From that point it is up to you if you send the token via a header or query string or whatever to your RESOURCE.

And as Brock said - that would be a question for the signalr team - I am actually interested in their response. Please ask them and let us know.

[billpratt]

SignalR/SignalR#3300