What is the standard way of an active client passing a SAML token to a relying party?

Question

I have a mobile client (iOS) and a web service (WCF, .NET 4.5) that I am securing using Windows Identity Foundation and SAML tokens. I have my client requesting SAML tokens from a custom STS, and once my relying party has that token I am able to deserialize it and verity its claims.

However, I am uncertain if there is a standard way to send the token from the client to the relying party? I am guessing the token should be in the header of each request, but is there a common header or cookie name that is used when passing this type of token?

I could see how you would want it to be different in all cases, in case multiple tokens were being passed back and forth, but I am wondering what the standard is for doing this.

Answer 1

If the RP is WCF, then yes.. the bindings all take care of that. If the RP is something else (such as a HTTP/REST service) then it's up to you and your protocol to send it. So yea, you can just send it as a HTTP header. The RP would then need to know to look for the token and validate it. This doesn't exist today in WebAPI, so you can use the Thinktecture IdentityModel security library to accept and validate tokens in HTTP headers:

http://thinktecture.github.io/Thinktecture.IdentityModel.45/

Answer 2

The more logical thing to do is to pass a JWT token (there is an official Microsoft implementation available on nuget). These are much smaller and are easier to handle on non .NET clients (such as JavaScript ...). Since they are smaller, you can pass them in an http header; typically "Authorization space Bearer space encoded JWT token". In you wep api you then need an httpfilter to interpret this data and authorize or reject the call. Of course, you can do the same with a SAML token. You will needed to encoded it somehow and it will add considerably to the size of your communication.