This isn’t really JWT specfic, but this example highlighted a question that’s been nagging me for a while. Once a web client has an authorization token, say JWT, why go through all the hurdles in this example (Lawnchair, retrieving the value from storage & attaching the header to every AJAX request, etc…) ?

Why not just use IdentityModel’s HeaderMapping capability and store the token in a cookie? This way it will be automatically transported with requests. I also won’t need to reinvent a persistent cross-session storage mechanism, like above.

I wanted an explicit model – that very much mimics the way you would deal with a “real” token service.
In particular I wanted to avoid coupling the session with a transport mechanism, since for non JS clients, that might mean that the session is coupled with the client HTTP connection (like a .NET cookie container).

But you are right – for a JS client the cookie solution would be much easier. But,

– Can you query the expiration of a cookie from JS? Maybe I want to pro-actively get a new session token before the old one expires.
– Cookies have a size limit, and I don’t really want to get into the business of chunking the token. Also allowd cookie size varies between browsers.

Thanks for the reply. Also, welcome to StackOverflow. I noticed you recently popped up so I upvoted some of your answers and added a Thinktecture-Ident-Model tag :-D.

FEATURE?
I wasn’t really asking for a feature…although I do think it would help ease adoption of ‘outsourced authentication’ in web scenarios. I like the decoupling. I like that the solution is applicable to more than just HTTP scenarios; although IdentityModel already wades deep into the HTTP river (e.g., attributes & message handlers, HeaderMapping tokens from cookies, etc..).

PRAGMATISM
I’m really just trying to piece together a coherent/holistic picture of how to integrate token based authentication into a *web app*. I’ve yet to find a major site that actually relies on a token for in-site authorization (as opposed to initial-auth/logon). Major sites that use a token service (like hotmail, gmail, stack overflow, etc…) all seem to take the token and convert the necessary parts into a cookie. Using a cookie seems to be the pragmatic decision. First, the cookie just flows with transport. Second, if you have restricted assets, like say images that are somehow restricted, it would be quite difficult to inject the www-authenticate header for requests that naturally flow from the browser loading the HTML.

SIZE CONSTRAINTS
As for size constraints, as a practical matter they exist & vary whether using HTTP Headers (8k – http://stackoverflow.com/questions/686217) or cookies (4k – http://stackoverflow.com/questions/3107140). The pragmatist in me also thinks that if I need to transport over 4k of claims for every request — you’re going to have issues in the web world, particularly with mobile scenarios. I understand the need to exceed 4/8k, but I see those as more of an initial logon, data-import or establish-an-account process, rather than “here is my token, can i view this web page?”.

I do not, however, see this as a significant limitation. If the cookie is not encrypted, the client can just read the ValidTo/expiration claim value inside the cookie. If the token is encrypted the client cannot read the upcoming expiration regardless of the transport methodology (wwwauth or cookie).

I see a few ways to address the shortcoming. One, if the coder is so inclined, he could add a buddy-cookie that sets the expiration time as a value. Ugly, but easy. Alternately, the client and web server need to have a process for re-authentication in place, irrespective of using a token, an old school session cookie, or whatever. Why not just have the web server return a HTTP 401 with an appropriate www-authenticate header, and additional information if so desired. The client then asks the token service for a refreshed token. The token server can respond with either a refreshed token (if appropriate), or a 401 indicating client needs to provide credentials anew.

Anyway, I’m new to the claims based authentication, but that’s my 2-cents.

wrt Feature:
Oh yeah this is used outside of HTTP (e.g. in SOAP) – WIF supports that pretty well out of the box. My library is just adding the missing pieces for HTTP.

wrt Token Expiration
I need to look up the OAuth2 spec – I think they have a special status code/reason for expired tokens.

I guess you can summarize like this:
For “native” clients, the token response approach is better (because there is no coupling with the http client)
For JS clients, the cookie approach is better (because it just works).

I guess I will add a switch to my config, so you can decide which style you want. On my todo list now ;)

I would like to use the cookie approach for my js client. Was this “switch” you mentioned ever added to the config? If not, is there an example of how to use the HeaderMapping functionality that Eric B mentioned above?

Hi there…
Is there a Issue or a (strange miss-) behavior known according to a cross-domain ajax calls (to the tokenservice whos adressed on an differed domain obviously) on Christians’ JavaScriptClients Example. e.g. file brokeredAuthentication.js.

Is it correct to say that the correct behavior of a CORS implementation depends on the browser that the client uses? Calling a web.api using a MVC 4 project with js and Ajax from an IE9 browser for example, is still not working if i implement CORS (access denied).

After the user is autheticated using a username/password (Membership) via basic authentication he recieves a token. This token is stored in a cookie and the tokenvalue is send in the following calls to the web.api. On my dev machine thinks worked ok, however when I uploaded this solution to Azure the access denied messages came up.

Just when I thought JSONP could be the solution, I found out that setting a custom header is not possible. So that’s is also no solution. Using a httpclient serverside connecting to the web.api has no issue, but using Ajax to fill a page with a lot of tiles is the prefered solution.

The web.api should also be available for mobile device using a native app or the browser.

@Josh – Cookies are not supported. I decided against it. A number of problems come with cookies – CSRF – sliding expiration etc. Go with the “token request” approach, which makes it much more painless to switch to a real token service at some point.

The link is broken to this project. I downloaded the latest 4.5 project and this web client is not included. Where can I find the code to include the JWT in each response to the client. In my scenario the token will be used in subsequent AJAX calls to other Web APIs.