Shraing same token between MVC client and WebAPI client

[programmer-pragmatic]

We are building a SPA which is mix of MVC views and WebAPI calls. It has multiple modules and each module's landing page is written as MVC view. We want to outsource 'Authentication/Authorization' to another server (implemented with Thinktecture's Identityserver3).

So when user tries to open my application (any module), he will transferred to Authentication/Authorization server, where he will enter details and log in. Once MVC view is rendered in browser, it hits the webapi for data. At this point, we do not want user to take back to idsvr server again as he has already logged in. I am not sure how to achieve this. As of now we have one single project that contains mvc view and webapi. We can create two different projects if requried (one for MVC view and another for webapi). I assume that both will be different clients on idsvr. MVC views will use "cookie" (token will be wrapped under it) whereas webapi will use plain bearer token.

I have not found a way to achieve the same.

Thanks In Advance Pragmatic

[leastprivilege]

OK - so what is the issue?

It sounds like you already have an access token.

[programmer-pragmatic]

Hi Dominick,

If I use Owin cookie option for my MVC view, how can I extract token from it and use it for the webAPI's hit?

Since my MVC views and webApi are in single project, should I use cookie? I think, cookie should not be used for webAPI. Should I create two different project (one for webapi and another for mvc) and use following code to register the client:

public static class Clients { public static IEnumerable Get() { return new[] { new Client { ClientName = "MVC Client", ClientId = "mvc", Flow = Flows.Implicit,

            RedirectUris = new List<string>
            {
                "https://localhost:44319/"
            },
            PostLogoutRedirectUris = new List<string>
            {
                "https://localhost:44319/"
            },
            AllowedScopes = new List<string>
            {
                "openid",
                "profile",
                "roles",
                "sampleApi"
            }
        },
        new Client
        {
            ClientName = "MVC Client (service communication)",   
            ClientId = "mvc_service",
            Flow = Flows.ClientCredentials,

            ClientSecrets = new List<Secret>
            {
                new Secret("secret".Sha256())
            },
            AllowedScopes = new List<string>
            {
                "sampleApi"
            }
        }
    };
}

}

But question remains the same, how can I use token exist in cookie in javascript and use it for webapi calls?

[leastprivilege]

There is no token in the cookie (unless you put it there explicitly).

I would suggest you do this walkthrough here: https://identityserver.github.io/Documentation/docsv2/overview/mvcGettingStarted.html

[programmer-pragmatic]

Thanks Dominick for prompt response. I misinterpreted that cookie contains the token. I got it right now. When a user logins through MVC app, a token in generated from server. Since I am using cookie based approach, i could not find a hook where I can get hold of this token. All I want is to pass this token to client side (javascript) and use it for WebApi2's request. Is it possible?

[leastprivilege]

Did you do the walkthrough?

—  cheers Dominick Baier

On 14 Sep 2015 at 13:46:42, programmer-pragmatic (notifications@github.com) wrote:

Thanks Dominick for prompt response. I misinterpreted that cookie does contains the token. I got it now. When a user logins through MVC app, a token in generated from server. Since I am using cookie based approach, i could not find a hook where I can get hold of this token. All I want is to pass this token to client side (javascript) and use it for WebApi2's request. Is it possible?

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

[programmer-pragmatic]

Got it. I missed that part earlier. Yes, I can use the token generated for MVC view for webapi. And I also wanted to make sure, WebAPI should not be accessible by cookie (to overcome the CSRF attack). That is also doable. Thanks you very much.

I had one more design question.

• We are building a SaaS web application which will deployed in cloud (Window Azure). It will have multiple instances in multiple regions.
• All instances will be independent and will not share anything between them.
• Each instance will be used by multiple tenants.
• Instances name will be like NA.MyWebApp.com (for north America region), EA.MyWebApp.com (for asia region) and so on.
• Each instance will have its own Identity server.
• Tenant's user can go to their home instance and log in.

But client also wants a common url like 'login.MyWebApp.com' which can be used by all usesr from any tenant to login to his respective instance.

We are planning to implement something similar to following:

• We can define a traffic manager in Azure, which will work on proximity. We will use 'login.MyWebApp.com' for it.
• Whenever user tries to login in using 'login.MyWebApp.com', url will be resolved to the nearest instance. For ex. If he is log in from US region, this url will be resolved to NA.MyWebApp.com.
• We can use ResourceOwner flow in this. When user will enter credentials and click on login button. Application will search user's home instance by looking into database. This database will be replicated in each instance which will store the tenant-instance mapping.
• User credentials will be sent to his home instance's identity server and in return, system will get token.
• System will generate a cookie and user will be redirected to his home instance.
• Domain of the cookie will be set to '.MyWebApp.com' so that it can be shared for all instances (which are using same domain but different subdomain).

These are some initial thoughts and may not be correct/feasible. It would be great if you share your thought on this. If you like, I can create another issue for this.

[leastprivilege]

please open a new thread for further questions