Skip to content
This repository has been archived by the owner on Sep 18, 2021. It is now read-only.

Using IdSrv v3 for SignalR #357

Closed
mauriciod73 opened this issue Sep 12, 2014 · 17 comments
Closed

Using IdSrv v3 for SignalR #357

mauriciod73 opened this issue Sep 12, 2014 · 17 comments
Labels

Comments

@mauriciod73
Copy link

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
Copy link
Member

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

@mauriciod73
Copy link
Author

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
Copy link
Member

You'd have to ask the SignalR folks.

@leastprivilege
Copy link
Member

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

@mauriciod73
Copy link
Author

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
Copy link
Member

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

@ghost
Copy link

ghost commented Sep 16, 2014

@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
Copy link
Member

nice!

@mauriciod73
Copy link
Author

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

Thanks!

@billpratt
Copy link

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

@leastprivilege
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

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
Copy link

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
Copy link
Member

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
Copy link

SignalR/SignalR#3300

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants