15

I'm configuring an Azure ACS STS and would like to know if there is any impact on security based on the following token formats or how they are used. The answers to this questions should apply to other STSs such as CA Siteminder, Ping Identity, ADFS and others. Here is the selection I see in my configuration portal:

enter image description here

The corresponding help link takes me to MSDN documentation that doesn't cover security questions like this.

Is the difference in Token Format merely the manner in which it is serialized:

  • The size of the token (that may round trip to the browser)
  • Fundamental differences in security
  • Differences in features and functionality

I have heard in several MSFT talks that SWT is an overly simplified version of SAML, and JWT is a not-yet-finalized standard by Google, IBM, and MSFT that should compromise on features between SWT and SAML.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536

4 Answers4

6

Better or worse is relative to the usage of the protocol. SAML has it's place and SWT/JWT/et al have their place. The SAML spec is pretty much set in stone, whereas SWT/JWT are really in their infancy and keep changing.

SAML has lots of knobs which makes it fairly complex and that's the enemy of good security, but everyone pretty much implements it the same way. SWT/JWT are fairly simple in design, but nobody can agree on a single bloody implementation standard and a lot of the public libraries used don't undergo security review.

It also depends on how the tokens are signed and how the keys used for signing are protected. Shared secrets tend to be more difficult to protect and PKI is a PITA, but others may disagree.

Steve
  • 15,155
  • 3
  • 37
  • 66
4

From security standpoint, there's not much difference between JWT and SAML token specs; it mostly boils down to supported signing and encryption algorithms (JWT is more limited in this regard; see https://datatracker.ietf.org/doc/html/draft-jones-json-web-token-10#appendix-A).

For this use case, in the end they both just provide claims (with all the necessary baggage, like expire times, audience etc.). HOWEVER, the linked site says ACS's implementation of JWTs does not support encryption and may therefore be "less" secure. This of course depends on your actual use case.

The same is true for SWT tokens, which don't support encryption at all. But this might actually not be a problem, as tokens can be transmitted over secure channel that provides confidentiality (e.g. HTTPS).

And from a non-security standpoint note that there might be a non-negligent performance difference (generally SAML putting the most strain on your resources).

Community
  • 1
blazee
  • 41
  • 1
  • ACS's **lack of encryption with JWT** is a very valid point, especially when using Facebook. Because it includes a claim containing a Facebook access token which is very long-lived (1 month). Even when your ACS JWT token is short-lived. – Bart Verkoeijen Aug 19 '15 at 08:46
1

At the end of the day I don't think really matters, since it's a preference of format. SAML 2.0 is set in stone but is very large and verbose (as XML tends to be). But in my personal preference these days with my own projects. I say try out JWT tokens, which is a token in JSON format. If your client applications span across different platforms, it might be a lot easier looking at and handling a JSON object.

My client applications are

  • Pure AngularJS application
  • iOS iPad and iPhone app
  • Windows 8 App
  • Android App

And it's guarded by a Web API that accepts authorization header tokens with all the payloads in JSON format, so JWT seemed like a logical choice for me. When you're completely in .NET, for the ease of everything just use a SAML token.

When you're blatantly spread outside of just the pure Microsoft World: I highly recommend using JSON as a format over any other available ones. JSON is the format of the modern web these days so you're pretty much guaranteed that as well.

Max Alexander
  • 111
  • 3
  • "Just use a SAML token". It's a little more complicated than that... ;) – Steve Mar 13 '13 at 18:16
  • Very true, it's more complicated than that :-P! But that's all I got for now (-_-'). At the end of the day it's practically a string you're going to be tossing around right? – Max Alexander Mar 13 '13 at 21:53
1

I realize this is an old question and I'm not a security expert by any means. However, my experience with Azure ACS and token types led me to three conclusions:

  1. SAML worked more-or-less out of the box. JWT was much more fiddly and I had to rely on blogs to get it working.
  2. The size of the cookies was equivalent between SAML and JWT. My demo app passed ~30 claims; I didn't see anything that justified the assertion that JWT is much lighter weight than SAML.
  3. The Identity and Access Visual Studio plug-in provided a means to set up a local STS that could potentially be used to mock tokens in development. JWT was not an option in this tool.

So I went with SAML.

Jamie Ide
  • 111
  • 2