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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
