8

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.

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 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 06 '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. – makerofthings7 Feb 06 '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 06 '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. – makerofthings7 Feb 06 '11 at 17:59
  • Just to clarify, yes, my clients will be browsing to my website from a hardened Windows 2008 R2 server. – makerofthings7 Feb 06 '11 at 18:50
  • Besides the referer issue, the excellent web-keys link in @D.W.'s post notes a number of other risks, and suggested mitigations, for using secrets in URLs. It isn't easy (though what is in security...). See e.g. RFC 3986: "URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies)." – nealmcb Feb 07 '11 at 03:37
  • 1
    Thanks for that RFC... I may push for disabling .js only, and keeping cookies as cookies (if done right) appear to be security benefit over URL-based authentication. – makerofthings7 Feb 07 '11 at 21:34
  • Why do you want to disable either Javascript or cookies, or both? What benefits will that provide? – D.W. Feb 08 '11 at 08:01
  • 1
    @D.W. It will allow my customers to view the site. As mentioned in an earlier comment, my customers will access my site from a Windows 2008 R2 server where my site will be in the restricted zone by default. Although the cookie request isn't prevented, I can see some people disabling cookies. After this thread, I may make it an unsupported configuration. – makerofthings7 Feb 08 '11 at 08:18
  • 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 09 '11 at 07:41

3 Answers3

4

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.

Steve
  • 15,155
  • 3
  • 37
  • 66
  • yfuhs +1 Thanks for the great answer. I added the comment above, please correct any mistakes I may have made. – makerofthings7 Feb 06 '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 04 '11 at 03:16
4

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.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • +1 this helped me on a few questions including the following one regarding JS on HTTP GETs http://stackoverflow.com/questions/4914994/using-mvc3s-antiforgerytoken-in-http-get-to-avoid-javascript-csrf-vulnerability – makerofthings7 Feb 07 '11 at 01:47
2

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.

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121