<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The problem as Facebook has discovered with their token leakage problem is that anyone who gets a access token for the protected resource (graph API or twitter api) can then use that token in the implicit/client side flow to impersonate the user in OAuth 2.0 bearer token. <div><br></div><div>The token for the resource is generaly longer lived than the users interactive session that wants to expire once the user logs out of the IdP. </div><div>Some people want the access token to be good for multiple endpoints until it is revoked.</div><div><br></div><div>(That reminds me, we need to say something about the grant lifetime for the scopes in openID for interoperability.)</div><div><br></div><div>We did discuss using a JWT for the access token so that it could do double duty. </div><div>Some people like Sales Force have existing code for there access tokens so they don't want to change that.</div><div>Another issue is token size, making the session token carry all of the scope information for the user-info and other endpoints may make the token too large to be practical.</div><div><br></div><div>It would also be more complicated for the RP to get right, than keeping the session and access grant tokens separate.</div><div><br></div><div>A common example of what not to do with OAuth from a privacy point of view is the twitter example of implicitly tying the identity to the grant of access to the persons twitter feed. </div><div>Allowing everyone you log into to post to twitter as you is perhaps not a good thing when generalized to a SSO solution.</div><div><br></div><div>The conversations I have had with NIST/GSA people indicate there strong preference for separating the session grant from other grants. They consider some of the existing OAuth systems vulnerable.</div><div><br></div><div>Perhaps a security review discussion is something we should add to the Sep meeting.</div><div><br></div><div>John B.</div><div><div><div>On 2011-08-17, at 9:19 PM, Allen Tom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi John - can you elaborate a bit more on why it's a "real security problem" in the Twitter case? Can you outline an example exploit?<div><br></div><div>Thanks</div><div>Allen</div><div><br><div class="gmail_quote">
On Tue, Aug 16, 2011 at 4:31 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The two tokens have potentially different scopes and lifetimes.<br>
<br>
There are good reasons for separating resource authorization from session authentication.<br>
<br>
It is true that twitter and others confuse those. That however is a real security problem.<br>
<br></blockquote></div></div>
</blockquote></div><br></div></body></html>