Supporting different token types: add Token Type to Authorization header?
Dick Hardt
I’ve switched to using the terminology being used in the IETF mail lists:
Protected Resource (PR, was Service Provider)
Client (was Consumer)
Server (was Token Issuer)
The scenario I am thinking of is where the Server can accept different types of Access Tokens. For example, a Server could accept a proprietary format in the near term, and then add another standard format in the future. A more likely scenario is that the Google and Microsoft my choose different token formats, and a customer may want to deploy a Server that can accept Access Tokens from either.
Currently in WRAP, the Client does not need to understand the Access Token, so having an different end point for the Server depending on token type goes against one of our design goals.
Do others think this is an important scenario? If so, here are what I see as being the options:
Option A: no explicit typing (current spec)
The PR and Server agree what the token looks like. If the PR accepts tokens from more than one Server and they are different token types, the Server must analyze the token to understand how to parse it.
The Client receives the following parameter from the Server:
wrap_token=dsjekascu3847y1ieklasd89h3d897qhwd98ahd
The Client sets the following HTTP header value when making an API call to the Server:
Authorization: WRAP dsjekascu3847y1ieklasd89h3d897qhwd98ahd
Advantages:
Only one token parameter is simpler for all parties if only one type of token is used by PR.
Disadvantages:
PRs that support more than one token type need to detect token type by examining token contents.
May not be viewed as compliant with HTTP header RFC.
Option B: embed type into
Example using type “foo”:
The Client receives the following from the Server (note the URL encoding):
wrap_token=wrap_foo%3D%94dsjekascu3847y1ieklasd89h3d897qhwd98ahd%94
The Client sets the following HTTP header value when making an API call to the Server:
Authorization: WRAP wrap_foo=”dsjekascu3847y1ieklasd89h3d897qhwd98ahd”
Advantages:
Easier for PR to detect token type.
Looks compliant with HTTP Header RFC (name=value)
Disadvantages:
Overloading type info into lvalue.
Token needs to be URL encoded in Server response.
Option C: additional parameter to indicate type
Example using type “foo”:
The Client receives the following from the Server:
wrap_type=foo&wrap_token=dsjekascu3847y1ieklasd89h3d897qhwd98ahd
The Client sets the following HTTP header value when making an API call to the Server:
Authorization: WRAP type=”foo”,token=”dsjekascu3847y1ieklasd89h3d897qhwd98ahd”
Advantages:
Simple to understand.
Provides simpler path for adding other token types.
Disadvantages:
There are two parts to Access Token rather then one.
Dick Hardt
Hello everyone
Any opinions here? If not, I’m leaning towards Option C.
-Dick
Brian Eaton
I like option C. This is more or less how SAML artifacts work: the
first few bytes of the artifact identify the issuer. The remainder of
the artifact is opaque.
I'm not a fan of the URL encoded name/value pairs. I'd lean towards
using JSON as the basis of the token format, because it is more
compact than XML, but is easier to work with than ASN.1. The only
part of the SAML artifact I don't like is the rigidity of the format.
We should have something extensible.
Straw-man:
json-token = {
issuer: 'issuer-name',
authenticator: 'token-from-server'
}
The client would then send:
Authorization: WRAP base64(json-token)
Cheers,
Brian
Dick Hardt
(SWT) and JSON.
We would then have:
Authorization WRAP format=SWT,token="SWT-token"
Authorization WRAP format=JWT,token="json-token"
Brian Eaton
> I was thinking that we would have both URL encoded name/value pairs
> (SWT) and JSON.
>
> We would then have:
>
> Authorization WRAP format=SWT,token="SWT-token"
> Authorization WRAP format=JWT,token="json-token"
Would that actually fix the problem you originally identified, where a
single client is talking to multiple token issuing services?
The difference there is not format, it is the issuing authority, right?
Cheers,
Brian
Dick Hardt
The issue is the Protected Resource is accepting Access Tokens from
multiple Servers (Token Issuers)
The Token Issuers might issue tokens in different formats. ie. Google
issues JWT and Microsoft issues SWT.
Brian Eaton
>> The difference there is not format, it is the issuing authority,
>> right?
>
> The issue is the Protected Resource is accepting Access Tokens from
> multiple Servers (Token Issuers)
> The Token Issuers might issue tokens in different formats. ie. Google
> issues JWT and Microsoft issues SWT.
So if the protected resource needs to validate a token, it needs to
know what authority issued the token, right?
That seems like a fundamentally bigger problem than the token format.
A SWT from MS and a SWT from Google are going to be signed with
different keys.
Cheers,
Brian
Dick Hardt
On 2009-10-10, at 8:30 AM, Brian Eaton wrote:
>
> On Fri, Oct 9, 2009 at 10:48 PM, Dick Hardt
> <Dick....@microsoft.com> wrote:
>>> The difference there is not format, it is the issuing authority,
>>> right?
>>
>> The issue is the Protected Resource is accepting Access Tokens from
>> multiple Servers (Token Issuers)
>> The Token Issuers might issue tokens in different formats. ie. Google
>> issues JWT and Microsoft issues SWT.
>
> So if the protected resource needs to validate a token, it needs to
> know what authority issued the token, right?
yep
> That seems like a fundamentally bigger problem than the token format.
> A SWT from MS and a SWT from Google are going to be signed with
> different keys.
Problem easily solved. Tokens include who issued them. SWTs have that
requirement.
If only a SWT can be used as a token in systems that interoperate, we
don't need the format parameter.
Andrew Arnott
Authorization header why not just define name as being "token" so it's
always:
Authorization: WRAP token="sometoken"
If we get rid of token type as a requirement, then this next issue
perhaps becomes a non-issue: why do we have to encode the token at
all? Choosing between URI encoding and JSON encoding, well, JSON
encoding is much more complex than URI encoding (think about escaping
strings within JSON objects, etc.) URI encoding/decoding is very
straightforward.
To summarize, if we have multiple data parts to send, let's leverage
the RFC's name=value pair system for sending those data and keep the
value part of it simple rather than making it a complex object.
Andrew Arnott
tokens from multiple token issuers? Wouldn't those issuers have to
share a database with the protected resource in order to validate the
token? Yes, signing could be used to avoid that step, but then you
get into token revocation lists, etc.
One might argue that these are short-lived tokens so if their
privileges are revoked they'll die soon enough anyway. But I'd
respond with "really?" In the Twitter scenario, you have hundreds of
Twitter clients, all moving to OAuth in order to appear "safe" to
users. Yet they still spam user accounts, and users RUSH to go deny
the app once they realize what they've done. If these apps have short-
lived but non-revocable tokens then they may have 30 minutes of "party
time" during which the user can do nothing to stop it. I think
revocable tokens are very important.
Dick Hardt
On 2009-10-13, at 11:21 AM, Andrew Arnott wrote:
>
> How would it work for a protected resource to be accessible based on
> tokens from multiple token issuers? Wouldn't those issuers have to
> share a database with the protected resource in order to validate the
> token?
Nope. This is a claims based identity model. The Protected Resource
could accept users from different Servers. The PR trusts each of the
Servers.
> Yes, signing could be used to avoid that step, but then you
> get into token revocation lists, etc.
>
> One might argue that these are short-lived tokens so if their
> privileges are revoked they'll die soon enough anyway. But I'd
> respond with "really?"
Really. That is the model.
> In the Twitter scenario, you have hundreds of
> Twitter clients, all moving to OAuth in order to appear "safe" to
> users. Yet they still spam user accounts, and users RUSH to go deny
> the app once they realize what they've done. If these apps have
> short-
> lived but non-revocable tokens then they may have 30 minutes of "party
> time" during which the user can do nothing to stop it. I think
> revocable tokens are very important.
Then they should use a shorter token life or a different protocol.
Dick Hardt
token is for, what authorization is associated with the token, when
the token will expire, how the token is signed. As soon as you start
looking at using PK for signatures, then you have another set of
values around the key.
For simple tokens where the values can be expressed as a set of name/
value pairs, the Simple Web Token format works. For more complex
tokens, JSON is a better serialization process rather then trying to
hack extra meaning into name/value pairs. There could be other token
formats as well.
The goal of WRAP is to define how and when to move the token. It does
not define the token. If different token formats are used, then the PR
and Server need a simple mechanism to signal the format.
Brian Eaton
>> In the Twitter scenario, you have hundreds of
>> Twitter clients, all moving to OAuth in order to appear "safe" to
>> users. Yet they still spam user accounts, and users RUSH to go deny
>> the app once they realize what they've done. If these apps have
>> short-
>> lived but non-revocable tokens then they may have 30 minutes of "party
>> time" during which the user can do nothing to stop it. I think
>> revocable tokens are very important.
>
> Then they should use a shorter token life or a different protocol.
There is nothing about WRAP that would stop someone from supporting
faster session token revocation than the session expiration time
provides.
In fact, the WRAP boundary on session token lifetime makes it easier
to build rapid revocation systems, using techniques like bloom filters
recording all revoked tokens.
Cheers,
Brian
Dick Hardt
I stand corrected, WRAP could be used where you check to see if the
token has been revoked with each call.
I would imagine most implementations would be looking for the
simplicity, scale and performance advantages of not doing revocation.
Not dissimilar to the practical deployment of SSL cert revocation in
browsers today from what I recall.
Brian Eaton
>>> I was thinking that we would have both URL encoded name/value pairs
>>> (SWT) and JSON.
>>>
>>> We would then have:
>>>
>>> Authorization WRAP format=SWT,token="SWT-token"
>>> Authorization WRAP format=JWT,token="json-token"
I think we should find a way to do that that allows (not requires)
tokens be "web safe". That would mean finding a way to encode format
that doesn't require any URL metacharacters like = or ?.
Cheers,
Brian
Dick Hardt
Would you elaborate? I can see making sure we can include the token in
the Authorization header without any further encoding, but URL
encoding of parameters moved to the Client is pretty standard and we
are already URL decoding the response from the Server like that.
-- Dick
Brian Eaton
>> I think we should find a way to do that that allows (not requires)
>> tokens be "web safe". That would mean finding a way to encode format
>> that doesn't require any URL metacharacters like = or ?.
>
> Would you elaborate? I can see making sure we can include the token in
> the Authorization header without any further encoding, but URL
> encoding of parameters moved to the Client is pretty standard and we
> are already URL decoding the response from the Server like that.
I expect people to write some fairly basic code to deal with these
tokens. That code will be more likely to work if service providers
can generate tokens that avoid all unusual characters.
Dick Hardt
Agreed the code needs to be straight forward, hence the use of
existing encoding/serialization techniques so that the Server and PR
developer is not doing anything special.
The Client should be able to take the "string" they received and plop
it in the HTTP header and be done.