My inclination for unstructured tokens is the size (20-30 bytes). I have some edge cases where my wireless bandwidth drops down to pathetically anemic rates, and every byte counts. Even the smallest JWT token that I was able to come up with (containing relevant material) was around 478 bytes. Of course if I had a JWT, then I might not even need to do the introspection at all. This would be interesting. In fact ... I originally started down a JWT path, but found OAuth implementation that could return a structured JWT access-token to be scarce. I could be misinformed though.
-adam From: George Fletcher [mailto:[email protected]] Sent: Friday, June 01, 2012 2:34 PM To: Lewis Adam-CAL022 Cc: [email protected] Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) I'm not sure why the dependency on the "unstructured token". You can have a small "structured" token which provides some additional capabilities. That said, as long as the RS can determine "which" AS the token came from, this solutions works well. I believe a few other implementations use a similar solution. I consider this definitely within the spirit of OAuth:) We chose to use structured tokens (JWS) which allowed us to specify the URL of the AS as well as a user identifier and some other data. Thanks, George On 6/1/12 9:59 AM, Lewis Adam-CAL022 wrote: Hi all, I've asked about the lack of standardization of the AS-RS interface in the past, but I have a new twist on my question. What is the viability of performing user "authentication" using OAuth with an RS in domain-1, and a whole bunch of AS's in different domains (assuming that the RS and AS is of the same implementation)? RS (domain-1) AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n Let me explain a bit further. I have a RS in domain-1 which exposes an API, which is accessed by a native client, with users from (for example) 12 different domains. (Note: both the RS and native clients are of the same vendor implementation). Each of the 12 user domains has an AS, of the same implementation as the RS in domain-1. I'm thinking that native client users from domain X should be able to authenticate to the AS in their home domain using some primary authentication means, obtain an unstructured access-token, and present that access-token to the RS in domain-1. Because they are all of the same implementation, the RS in domain-1 should be able to make a RESTful API call to the AS in domain X to obtain a JSON structure, containing among other things, the user's name, and possibly other attributes. Hence secondary authentication has been realized. This seems to work, but is this within the spirit of OAuth, or have I gone off into LaLa land? We have looked at using the SAML bearer assertion profile for OAuth, but we do a lot over wireless links, many of which are bandwidth anemic, and the overhead of obtaining the SAML assertion and sending it are making me a bit squeamish. OAuth is attractive because of its light weight-ness. Is the usage I'm proposing of OAuth (above) something that would be within the overall spirit of the OAuth framework? Tx! adam _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
