I'm looking for an authentication system that relies on 3rd parties (ADFS, OpenID, SAML) but doesn't rely on cookies or Javascript... or at least can make them optional.

My intent is to gracefully degrade and maintain state not in a cookie , but rather keep the session information in a HTTPS protected URI, that is repeated for each request.

What authentication systems support this primitive browsing?

Although this question doesn't directly deal with my webserver (and it shouldn't matter anyways) I would appreciate it if you could mention what authentication library works best or doesn't work for a given provider:

A helpful answer will tell me what technology supports or does not support cookie-free sign in, and what supports .js free sign in

  • Google OAuth:

  • Open ID

  • Facebook

  • LinkedIn

  • ADFS

  • ???

A GREAT answer will tell me the technology and the corresponding library that works with is

  • WIF works without cookies or Javascript. Protocol is WS-Auth/Fed with ADFS Server. (ref)

  • WIF ??? with WS-Fed (+SAML Token) Protocol with ADFS Server.

  • LinkedIn ToolKit:

  • Facebook Integration API:

  • DotNetOpenAuth:

The idea is that even though an underlying technology may support cookie free and JS free authentication, the corresponding library is implemented in a way that does not support this.

Please contribute whatever knowledge you have so I can triage the information into a nice summary for the benefit of all.

  • 2
    Classic HTTP is stateless without cookies, and you need some sort of state to preserve a security association with the web site. Perhaps you should clarify what your underlying concerns are about using cookies and javascript. Basic Auth fulfills your requirements but has a terrible user experience. – nealmcb Feb 6 '11 at 16:24
  • 1
    I can maintain state with a string in the HTTP GET even though it makes for ugly URLs. ASP.NET supports this. I believe MVC does too. My focus is not on my web server technology, but in finding an authentication partner and technology that works well without JS and cookies. – goodguys_activate Feb 6 '11 at 17:18
  • 3
    Your edits help a whole lot - thanks. But putting session ids in URLs makes your users and site vulnerable to session-ID theft via the "Referer" header, and breaks REST-fulness. So more background on the context and risk profile you're trying to address would help. – nealmcb Feb 6 '11 at 17:53
  • 1
    All off-site links will be relayed though a redir.aspx, should address that referer issue. I'm building a website that should run well on a default Windows 2008 R2 IE installation where all security features are enabled.. perhaps everything. No .JS is confirmed. No cookies too is likely. – goodguys_activate Feb 6 '11 at 17:59
  • 2
    OK, thanks. Yeah, I think you should re-examine your assumed constraints. Yes, it's entirely reasonable to assume the user will have to leave cookies enabled, if they want to use your site; cookies are widely used on the web for session management. – D.W. Feb 9 '11 at 7:41

ASP.NET out of the box can handle cookieless session handling. As such, any mechanism that uses ASP.NET sessions can work cookie-less. The Windows Identity Foundation coupled with ADFS v2 will work cookieless, but every time you return back to the STS, you will need to reauthenticate so you don't get SSO.

WIF will work with MVC.

I cannot speak to any other platforms as my specialty is WIF/ADFS.

EDIT: JavaScript is not required for either. Also, WIF will handle SAML tokens, but doesn't handle the protocol itself. V1 only supports WS-Auth/Fed.

  • yfuhs +1 Thanks for the great answer. I added the comment above, please correct any mistakes I may have made. – goodguys_activate Feb 6 '11 at 18:55
  • 2
    Isn't it a bad idea to use cookieless sessions? Doesn't that, for example, enable session hijacking and session fixation? – atdre Apr 4 '11 at 3:16

One approach is to use "capability URLs", where the URL contains a secret token. Knowledge of the token is all that is needed to access the resource.

To learn more about this approach, read about web-keys and the web-calculus. (One person mentioned the risk of secret tokens leaking through the Referer: header; see the web-keys paper for a method to mitigate that risk.) However, don't expect this approach to be an easy drop-in modification to an existing application.


OpenID works without JavaScript. Only openid-selector which is commonly used requires JavaScript but falls back gracefully by just display the openid input field.

In our application we don't use the openid-select JavaScript, but static images with links to Google, Yahoo and MyOpenId.

We don't have shortcuts for all those other openid providers because Google, Yahoo, MyOpenId are the ones commonly used. The other ones require entering of the user name before doing the redirect which is very inconvenient and not doable without JavaScript.

In addition we have the standard openid input field.

The cookie questions was discussed in the comments on the original posting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.