On 5/20/2014 10:04 AM, Sergey Beryozkin wrote:
Hi,
Thanks for the clarification,
On 20/05/14 14:03, Brian Campbell wrote:
Yes Sergey, it's to allow for support of unregistered clients. Typically
such clients will have some relationship established with a security
token service (STS) where they can obtain assertion grants and the AS
trusts the STS to issue such assertions. In that kind of scenario, the
identity of the client can be considered unimportant - what's important
is that the AS trusts the STS and in turn the STS trusted the client
enough to issues it a suitable assertion.
What confuses me still is this: given a grant (whatever grant it is) AS
issues a token which is associated with a given client somehow.
When a registered client uses JWT or SAML assertion to authenticate it
is all clear (I can imagine the client logs on to STS, gets the
assertion and authenticates with it to AS).
Now if we have an unregistered client using an assertion grant, how do
we associate a token with this unregistered client, the text seems to
imply that the assertion grant does not identify this unregistered
client either, so it is not clear how this client can use the token
afterwards, even though AS can validate with STS/etc that the grant is
valid.
Is the idea that the registration happens after the unregistered client
has exchanged an assertion grant for a token ?
Sorry, I know I'm missing something obvious here...
The unregistered client could, out-of-band, get its own token with the
appropriate claims. The unregistered client would use this token as a
credential when asking for an access token.
I think what this setup allows you to do is to have a federated set of
STS services. Where one STS deals with providing access tokens for
applications and another deals with providing access tokens for clients
to access application STS services :) Instead of just one auth server
having to know about everything, you can delegate things to different
servers.
Am I on the right track?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
