Subject: [OAUTH-WG] application/credentials

From: "Manger, James H" <[email-masked]>
Date: Sat, 17 Apr 2010 01:38:10 +1000

One thing missing from the current access token responses is any indication of where the token can be used.

This seems potentially dangerous as the token might be included when, say, following links or redirects from a protected resource.

The solution is probably fairly easy: specify the list of services where the token can be used when the token is issued.

1. A list of domains?

2. A list of “origins” (scheme://host:port)?

3. Allow a wildcard, eg *.example.com?

I’ll pick #2.

Example: sites=https://api.example.com http://photo.example.com

Others have noted the similarities between a bearer token and a cookie. Cookies indicate where they can be used. They also have some other meta-data that might help tokens. For instance, a ‘secure’ field indicating that the token must not be used without https.

All this information describing the token deserves its own media type.

My suggestion: application/credentials.

It could keep the existing syntax, but a little more structure from a syntax such as JSON might be easier. That would also make it easier to include multiple tokens (eg a bearer token, another with a secret, another for a specific service).

The refresh_token field would be better thought of as a URI for a token resource.

Example:

C->S:

  POST /token/ HTTP/1.1

  …

C<-S:

  HTTP/1.1 200 OK

  Content-type: application/credentials

  {

    “location”:”http://as.example.com/token/76875634576387634765374”,

    “expires_in”:3600,

    “credentials”:{

     { “scheme”:”TOKEN”, “sites”:[“https://api.example.com”, “http://photo.example.com”],

         “realm”:”General apps”, “id”:”HGF676t7f6f7F67ffr76ff” },

     { “scheme”:”BASIC”, “sites”:[“https://blog.example.com”],

         “realm”:”General apps”, “id”:”dGFDdd464464Ddfd”, “secret”:”tutvT67vV76tvTtvTvTv” }

    }

  }

Use the “location” field to refresh (or delete) the token.

--

James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Apr 2010 10:40:39 +0200

elegant design :-) which raises an important question to me:

If we would design any API for the web we would probably use mime types 
and JSON/XML for transporting data.

Why don't we use similar techniques for the OAuth authorization API?

regards,
Torsten.

BTW: Our security token service at Deutsche Telekom does it that way. 
Developers like the easy way they can authenticate, access identity data 
and integrate these functions into their applications.

Am 16.04.2010 17:38, schrieb Manger, James H:
>
> One thing missing from the current access token responses is any 
> indication of where the token can be used.
>
> This seems potentially dangerous as the token might be included when, 
> say, following links or redirects from a protected resource.
>
> The solution is probably fairly easy: specify the list of services 
> where the token can be used when the token is issued.
>
> 1. A list of domains?
>
> Others have noted the similarities between a bearer token and a 
> cookie. Cookies indicate where they can be used. They also have some 
> other meta-data that might help tokens. For instance, a ‘secure’ field 
> indicating that the token must not be used without https.
>
> It could keep the existing syntax, but a little more structure from a 
> syntax such as JSON might be easier. That would also make it easier to 
> include multiple tokens (eg a bearer token, another with a secret, 
> another for a specific service).
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>