On 08/03/13 01:36, geecxf wrote:
I'll be sure to share whatever I learn if we are tasked to implement this
kind of functionality. So far our product owners are saying this is not
strictly necessary but that could change.
Regarding OAuth, the last time I read the specification it was essentially
token agnostic. Other than the fact that the token should be compact so that
you can pass it in redirects and headers, the specification really says
nothing about what token format to use. I think JWT is what most people are
using but I've also seen implementations that return SAML assertions. MS
also has a Simple Web Token (SWT) format which is a basically JWT light. But
I digress.
The actual token is opaque but the grant can take whatever form is
required, it can be as opaque as a token itself or a may have some
encoded information carried along the way. So the grant can optionally
be an assertion (SAML or JWT), to be exchanged for an opaque token.
The token can then can be used by RS or even WS consumers - the latter
will be supported shortly, so one can imagine a different pattern even
for WS consumers, where OAuth2 is used to acquire the tokens out of
band, possibly with the use of SAML/etc assertions and then WS consumers
only use these binary tokens. I think this pattern will get more
visibility as OAuth2 itself becomes more deployed
Cheers, Sergey
--
View this message in context:
http://cxf.547215.n5.nabble.com/SAML-metadata-tp5723816p5724286.html
Sent from the cxf-user mailing list archive at Nabble.com.
