The classical OAuth flow involves the authorized 3rd-party client magically accessing the end user's resources without even specifying a user name or id, for example:
GET /user/calendar
How can the server figure out which resource to return ? The answer is that the request will have an Authorization header with an access token key and in OAuth 1.0 the token needs to get the information about the end user authorizing a given 3rd party consumer associated with it at the authorization time.
With this association in place, the server will have an easy way to get to the name or id of the user used to authorize the client, and the way to do it in soon to be released CXF 2.5.1 is documented here.
I'd like to thank Glen for helping me with getting this enhancement done.
We are continuing working on the demo which will show most of the CXF OAuth support in practice. Please stay tuned to see how you can write secure OAuth applications with CXF :-)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment