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

Multiple apps using same clientid #2662

Closed
molnara opened this issue Mar 3, 2016 · 7 comments
Closed

Multiple apps using same clientid #2662

molnara opened this issue Mar 3, 2016 · 7 comments
Labels

Comments

@molnara
Copy link

molnara commented Mar 3, 2016

Question

I have the following sub domains:

idsvr.lab.local
client1.lab.local
client2.lab.local

When I login to client1, I was expecting to automatically be logged into client2, as this happens when I am developing using localhost.(Also they are both using the same clientid, but I also tried seperate clientids) I have to click the login button on client2, which then redirects to idsvr and then back to client2. Sorry, if someone already asked this question, having trouble searching for this issue.

Thanks in advance for any guidance.

@thabart
Copy link

thabart commented Mar 3, 2016

Hi molnara,
I don't think the issue is coming from identity server.
If you're using exactly the same "client-authentication" mechanism (client_basic / client_private_key) & passing the client credentials
And if your user agent has already been authenticated against identity server (check the cookie)
And if the consent has been confirmed by the resource owner then indeed identity server directly returns the identity token / access token to the callback.
Be careful ! those steps are only valid for the implicit & hybrid flows.

If all those steps are ok, then the issue is probably coming from one of your client.
The same cookie (same name) needs to be used by both client to authenticate your HTTP request.

@leastprivilege
Copy link
Member

Every client must do its own authentication roundtrip - but the user only has to login once.

I would advise against sharing cookies between clients - this will have side effects down the road. Also each client might need different claims.

@molnara
Copy link
Author

molnara commented Mar 4, 2016

thanks for the response thabart. I checked cookie names, all default to what identity server generates( .Aspnet.Cookies and ARRAffinity?). Using implicit flow(Flow in dbo.Client table is 2) (response_type= code id_token token). I did set RequireConsent = false as I don't need that feature. Secrets are all the same. So strange why this works fine on localhost, like the sub domain has something to do with it?

Also what do you mean by client_basic and client_private_key? I don't see these anywhere in the documentation?

Thanks again for your help.

@molnara
Copy link
Author

molnara commented Mar 4, 2016

sorry leastprivilege, didn't see your post before I replied, thanks. So you mean if I want the user to be logged in, I need to set like the home controller to have an [Authenticate] to automatically do a round trip to identityserver? On localhost this is not necessary for some reason if the user is already logged in from another website.

@thabart
Copy link

thabart commented Mar 4, 2016

Even if your HomeController is decorated with the Authenticate attribute, the issue will not be fixed. When you're using an authentication middleware like "CookieAuthentication", it's trying to fetch the cookie from the HTTP request header, validate it & set the current thread.
Don't forget that the scope of a cookie is restricted to the request host. If a cookie is generated by your first-client then it is only valid on the client1.lab.local host (HTTP request header : Set-Cookie: name=value, client1.lab.local), because of its validity constraint it cannot be reused to authenticate the request against client2.lab.local

A workaround is to generate a cookie valid for the domain "lab.local" example :

HttpCookie hc = new HttpCookie("key", "value");
hc.Domain = ".lab.local"; // must start with "."
hc.Expires = DateTime.Now.AddMonths(3);
HttpContext.Current.Response.Cookies.Add(hc);

I'm not a very big fan of using shared-cookie because you open security breach to "cross-subdomain cookie attacks"

Note : In my previous comment I mentionned the different ways to authenticate the client (client_secret_basic & client_secret_post ...) you can take a look here : http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

@molnara
Copy link
Author

molnara commented Mar 4, 2016

Adding the [Authorize] attribute worked. If all these web application, all used by same company on same sub domains and use the same authentication, is it best practice to use one clientid or seperate clientid for each web application?

@thabart
Copy link

thabart commented Mar 4, 2016

Its better to have separate clients because they can have different scopes

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

3 participants