Handling Authentication with both Web App and API

Question

Not sure how to handle this. Our current app (.Net MVC) is accessed via companyname.appname.com, authentication is handled via forms (cookie) authentication. Within the app there is a global search box that is quite heavily used, we are looking to split this out into it's own microservice so all calls for search will go to something like search.appname.com instead, therefore lightening the load on the main app.

The question we have is about how best to authenticate the calls to that url. We can't share cookies across sub-domains as all clients have a different sub-domain and the sharing cannot be restricted to a select no. of domains (or not to my knowledge).

Do we return an API token when they first login that we store and use for API calls or is there another way?

Answer 1

Cookies on the domain .appname.com should be sent to both companyname.appname.com and search.appname.com so you can potentially use the same cookie.

However, all "cookie authentication" means is that the token is stored in a cookie. If you have "standard out of the box" cookie auth on your .net MVC site you will need to have bother the same setup and share machine keys with your api. Which is not always the best solution.

If you implement oauth and use a json token with claims in a central single sign on auth service you can reuse that token across all your sites and apis. Sending it in a cookie or a header as best fits your application.

Say for example your site is on domain1.com and your search is on domain2.com and your auth is on domain3.com. You can have the website call auth via javascript to get the token. Set that token as a cookie on domain1.com so that you can browse the site AND pass it as a header when you make api calls to the api domain2.com in javascript.

Answer 2

There are many ways to do this, but here is the simplest I can think of without changing your overall architecture and standing up a new identity server.

1. User signs on to MVC web site and receives his forms auth cookie, as usual.
2. MVC site returns a page to the browser.
3. The page makes an AJAX request to a handler (within your MVC web site) to get an authentication token for the API
4. The handler authenticates the request using the forms cookie, just like the rest of your site. It then issues a single-use token that the API will be able to parse. The token is returned in a redirect header; the path of the URL points a handler within the web API and the query string contains the token.
5. The browser follows the redirect, i.e. bounces the request to the API handler.
6. The handler in the API reads the URL and parses the token. It then issues an authentication cookie of its own and returns it to the browser.
7. At this point the browser has two cookies, one for accessing the site and one for the API.

The token itself could be a shared random value, if your API and site share the same database. If they do not share the same database, it could be an encrypted timestamp using a shared secret key.