When you don't have anything nice to say, well then perhaps its time consider a career as an analyst.
Thursday, October 02, 2008
Comparing OAuth & ID-WSF Authz Models
A first stab at looking at how OAuth and Liberty ID-WSF support user consent, requestor authorization, and subsequent access of protected identity resources
You probably thought about this too, but just in case you didn't.....
I tend to view OAuth conceptually as a simplified deployment of an ID-WSF setup where:
1) the Consumer does not do discovery; it has "hard wired" knowledge of the whereabouts of the Provider
2) the Consumer sends an "unauthorized" request but (implicitly in OAuth case) is willing to engage in a InteractionRedirect dance
3) the Provider asks the Consumer to redirect the user/browser to itself to obtain "consent". And in practically all OAuth cases to authenticate the user, perhaps based upon a cookie, but nevertheless.
4) Once the Provider is happy with the browser it redirects back to the Consumer with an indication of "now go ahead".
5) The Consumer makes it request "referring" to the "go ahead" from the Provider. So the Provider reply mdg id is approx. the "use token" in OAuth.
I personally feel that *the* really crucial difference is actually 1), when combined with ID-SIS specs. It is just such a powerful idea that my contact book, or friend list (people service) could be anywhere.
Anyway doc looks good, don't feel obliged to take my musings into account; only trying to provide another perspective.
1 comment:
You probably thought about this too, but just in case you didn't.....
I tend to view OAuth conceptually as a simplified deployment of an ID-WSF setup where:
1) the Consumer does not do discovery; it has "hard wired" knowledge of the whereabouts of the Provider
2) the Consumer sends an "unauthorized" request but (implicitly in OAuth case) is willing to engage in a InteractionRedirect dance
3) the Provider asks the Consumer to redirect the user/browser to itself to obtain "consent". And in practically all OAuth cases to authenticate the user, perhaps based upon a cookie, but nevertheless.
4) Once the Provider is happy with the browser it redirects back to the Consumer with an indication of "now go ahead".
5) The Consumer makes it request "referring" to the "go ahead" from the Provider. So the Provider reply mdg id is approx. the "use token" in OAuth.
I personally feel that *the* really crucial difference is actually 1), when combined with ID-SIS specs. It is just such a powerful idea that my contact book, or friend list (people service) could be anywhere.
Anyway doc looks good, don't feel obliged to take my musings into account; only trying to provide another perspective.
Post a Comment