Re: [OAUTH-WG] Comments on Web Callback Client Flow
On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert uid...@google.com wrote: On Wed, Apr 7, 2010 at 9:29 AM, John Panzer jpan...@google.com wrote: I'm assuming that tokens need not be bound to a specific user (typically they are, but imagine a secretary granting an app access to his boss's calendar and then leaving the company and therefore being removed from the calendar ACL, but the app still keeping access by virtue of the capability granted by the token). In this case, the proposed wording seems kind of problematic for a MUST. Note that the resource owner in this case is the secretary, not his boss. Resource owner is An entity capable of granting access to a protected resource. Since access tokens are bound to the resource owner (A unique identifier used by the client to make authenticated requests on behalf of the resource owner.), I think in this case the system would have a clear way to revoke access to the document. Sorry, I was unclear. In the scenario I'm imagining, the boss has delegated calendar access to his secretary, who uses this delegated access to hook up an app to the calendar. The boss is very happy with this situation because now his Zombieville reminders show up on his calendar. If the token is tied to the secretary, and the secretary's account is shut down when the secretary leaves, then the boss no longer sees the Zombieville reminders pop up. He then complains that this sort of thing never happened with password-based access! I can imagine either scenario upon termination of the secretary -- you may want to revoke all the tokens, some of the tokens, or none of the tokens. Updating the wording on the proposal slightly to clarify (also changing format to new parameter formatting) Before: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username Current: username OPTIONAL. The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens *capable of making requests on behalf of* the user identified by username On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert uid...@google.com wrote: On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav e...@hueniverse.comwrote: What about an attacker changing the username similar to the way a callback can be changed? I don't think there is a danger here. We still use all of the safeguards in place from the rest of the flow - adding this parameter never log you in when omitting the parameter would not have. It will just create more error responses. EHL On 4/6/10 11:14 PM, Evan Gilbert uid...@google.com wrote: On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: On 4/6/10 5:24 PM, Evan Gilbert uid...@google.com wrote: Proposal: In 2.4.1 2.4.2, add the following OPTIONAL parameter username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username. What are the security implications? How can the client know that the token it got is really for that user? Think the client has to trust the auth server, in the same way as with the username + password profile. The auth server can always send back a scope for a different user. Worst case is that there is an identity mismatch between client and the identity implicit in the authorization token. This mismatch is already possible, and I don't think the username parameter makes the problem worse. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on Web Callback Client Flow
On Wed, Apr 7, 2010 at 11:40 PM, John Panzer jpan...@google.com wrote: On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert uid...@google.com wrote: On Wed, Apr 7, 2010 at 9:29 AM, John Panzer jpan...@google.com wrote: I'm assuming that tokens need not be bound to a specific user (typically they are, but imagine a secretary granting an app access to his boss's calendar and then leaving the company and therefore being removed from the calendar ACL, but the app still keeping access by virtue of the capability granted by the token). In this case, the proposed wording seems kind of problematic for a MUST. Note that the resource owner in this case is the secretary, not his boss. Resource owner is An entity capable of granting access to a protected resource. Since access tokens are bound to the resource owner (A unique identifier used by the client to make authenticated requests on behalf of the resource owner.), I think in this case the system would have a clear way to revoke access to the document. Sorry, I was unclear. In the scenario I'm imagining, the boss has delegated calendar access to his secretary, who uses this delegated access to hook up an app to the calendar. The boss is very happy with this situation because now his Zombieville reminders show up on his calendar. If the token is tied to the secretary, and the secretary's account is shut down when the secretary leaves, then the boss no longer sees the Zombieville reminders pop up. He then complains that this sort of thing never happened with password-based access! I can imagine either scenario upon termination of the secretary -- you may want to revoke all the tokens, some of the tokens, or none of the tokens. This seems to be an issue with all of the delegation profiles, and not related to the username parameter. Note that expected behavior in this case is unclear. If the secretary has installed an app on her cell phone to view his boss' calendar, you clearly do want to revoke access. Updating the wording on the proposal slightly to clarify (also changing format to new parameter formatting) Before: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username Current: username OPTIONAL. The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens *capable of making requests on behalf of* the user identified by username On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert uid...@google.com wrote: On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: What about an attacker changing the username similar to the way a callback can be changed? I don't think there is a danger here. We still use all of the safeguards in place from the rest of the flow - adding this parameter never log you in when omitting the parameter would not have. It will just create more error responses. EHL On 4/6/10 11:14 PM, Evan Gilbert uid...@google.com wrote: On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: On 4/6/10 5:24 PM, Evan Gilbert uid...@google.com wrote: Proposal: In 2.4.1 2.4.2, add the following OPTIONAL parameter username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username. What are the security implications? How can the client know that the token it got is really for that user? Think the client has to trust the auth server, in the same way as with the username + password profile. The auth server can always send back a scope for a different user. Worst case is that there is an identity mismatch between client and the identity implicit in the authorization token. This mismatch is already possible, and I don't think the username parameter makes the problem worse. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on Web Callback Client Flow
On Wed, Apr 7, 2010 at 11:21 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: I will leave this to the security folks to decide but it seems to me that if the client asks to limit the username of the end user granting access by specifying it in the request, the server must repeat that information when issuing such a token. Otherwise, an attacker can force a user to grant access to another account (for example, if they have both a personal and work accounts on the same server) without the client being able to detect it. In other words, if the client can demand an access token for a specific username, it should be able to have the absolute confidence (assuming it trusts the server) that the access token received has that attribute. Note: I'm fine with adding a username in the response if it helps from the security side. It's not clear to me that there's a security hole, but it never hurts to provide more information in the response back. EHL On 4/7/10 10:46 PM, Evan Gilbert uid...@google.com wrote: On Wed, Apr 7, 2010 at 9:29 AM, John Panzer jpan...@google.com wrote: I'm assuming that tokens need not be bound to a specific user (typically they are, but imagine a secretary granting an app access to his boss's calendar and then leaving the company and therefore being removed from the calendar ACL, but the app still keeping access by virtue of the capability granted by the token). In this case, the proposed wording seems kind of problematic for a MUST. Note that the resource owner in this case is the secretary, not his boss. Resource owner is An entity capable of granting access to a protected resource. Since access tokens are bound to the resource owner (A unique identifier used by the client to make authenticated requests on behalf of the resource owner.), I think in this case the system would have a clear way to revoke access to the document. Updating the wording on the proposal slightly to clarify (also changing format to new parameter formatting) Before: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username Current: username OPTIONAL. The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens capable of making requests on behalf of the user identified by username On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert uid...@google.com wrote: On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: What about an attacker changing the username similar to the way a callback can be changed? I don't think there is a danger here. We still use all of the safeguards in place from the rest of the flow - adding this parameter never log you in when omitting the parameter would not have. It will just create more error responses. EHL On 4/6/10 11:14 PM, Evan Gilbert uid...@google.com http://uid...@google.com wrote: On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav e...@hueniverse.com http://e...@hueniverse.com wrote: On 4/6/10 5:24 PM, Evan Gilbert uid...@google.com http://uid...@google.com wrote: Proposal: In 2.4.1 2.4.2, add the following OPTIONAL parameter username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username. What are the security implications? How can the client know that the token it got is really for that user? Think the client has to trust the auth server, in the same way as with the username + password profile. The auth server can always send back a scope for a different user. Worst case is that there is an identity mismatch between client and the identity implicit in the authorization token. This mismatch is already possible, and I don't think the username parameter makes the problem worse. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on Web Callback Client Flow
On 4/6/10 5:24 PM, Evan Gilbert uid...@google.com wrote: Proposal: In 2.4.1 2.4.2, add the following OPTIONAL parameter username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username. What are the security implications? How can the client know that the token it got is really for that user? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on Web Callback Client Flow
On Wed, Apr 7, 2010 at 9:29 AM, John Panzer jpan...@google.com wrote: I'm assuming that tokens need not be bound to a specific user (typically they are, but imagine a secretary granting an app access to his boss's calendar and then leaving the company and therefore being removed from the calendar ACL, but the app still keeping access by virtue of the capability granted by the token). In this case, the proposed wording seems kind of problematic for a MUST. Note that the resource owner in this case is the secretary, not his boss. Resource owner is An entity capable of granting access to a protected resource. Since access tokens are bound to the resource owner (A unique identifier used by the client to make authenticated requests on behalf of the resource owner.), I think in this case the system would have a clear way to revoke access to the document. Updating the wording on the proposal slightly to clarify (also changing format to new parameter formatting) Before: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username Current: username OPTIONAL. The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens *capable of making requests on behalf of* the user identified by username On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert uid...@google.com wrote: On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav e...@hueniverse.comwrote: What about an attacker changing the username similar to the way a callback can be changed? I don't think there is a danger here. We still use all of the safeguards in place from the rest of the flow - adding this parameter never log you in when omitting the parameter would not have. It will just create more error responses. EHL On 4/6/10 11:14 PM, Evan Gilbert uid...@google.com wrote: On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: On 4/6/10 5:24 PM, Evan Gilbert uid...@google.com wrote: Proposal: In 2.4.1 2.4.2, add the following OPTIONAL parameter username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username. What are the security implications? How can the client know that the token it got is really for that user? Think the client has to trust the auth server, in the same way as with the username + password profile. The auth server can always send back a scope for a different user. Worst case is that there is an identity mismatch between client and the identity implicit in the authorization token. This mismatch is already possible, and I don't think the username parameter makes the problem worse. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on Web Callback Client Flow
On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav e...@hueniverse.comwrote: Hi Evan, On 4/5/10 4:28 PM, Evan Gilbert uid...@google.com wrote: 2.4.1 Web Callback Flow 2.4.2 Web Client Flow In both flows, the authorization server should be able redirect back to the callback URI without interacting directly with the resource owner if access has already been approved. This is not ruled out in the current language but it could be made cleaner. Suggested rewording - change After receiving an authorization decision from the resource owner, the server redirects the resource owner to the callback URI. to If the client is already approved or denied for access to the protected resource, the authorization service MAY redirect the resource owner to the callback URI immediately. If not, the authorization service SHOULD ask the resource owner for an authorization decision and after receiving the decision redirect the resource owner to the callback URI. I opted for a simpler change: 'After receiving (or establishing via other means) an authorization decision' Sounds great 2.4.1 Web Callback Flow 2.4.2 Web Client Flow We should have an OPTIONAL username parameter: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for this user. This is useful for clients where a user is already logged into a 3rd party web site with a specific account, and the client wants the authorization to match the specific user. I think introducing the concept of user identity is more complex than just a username parameter. I agree that it can be useful but we need a more detailed discussion about this before we add it. I agree issues around user identity are complex. Would it help to spin up a separate discussion thread on this one issue? 2.4.2 Web Client Flow Sending an access token as a query parameter is dangerous from a security perspective - these tokens are leaked via referrers and server logs. In previous WRAP discussions, it was felt that we should have a strong recommendation to use the URL fragment. Suggested wording: Client SHOULD send a callback URI with a query fragment, and authorization server MAY reject callback URLs without a fragment for security reasons. Why not require it? I made the assumption that someone had use cases that drove the examples in the spec. I would be OK with requiring it. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on Web Callback Client Flow
The web client flow was intended to require either a fragment or SSL (or optionally both). On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert uid...@google.com wrote: On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Hi Evan, On 4/5/10 4:28 PM, Evan Gilbert uid...@google.com wrote: 2.4.1 Web Callback Flow 2.4.2 Web Client Flow In both flows, the authorization server should be able redirect back to the callback URI without interacting directly with the resource owner if access has already been approved. This is not ruled out in the current language but it could be made cleaner. Suggested rewording - change After receiving an authorization decision from the resource owner, the server redirects the resource owner to the callback URI. to If the client is already approved or denied for access to the protected resource, the authorization service MAY redirect the resource owner to the callback URI immediately. If not, the authorization service SHOULD ask the resource owner for an authorization decision and after receiving the decision redirect the resource owner to the callback URI. I opted for a simpler change: 'After receiving (or establishing via other means) an authorization decision' Sounds great 2.4.1 Web Callback Flow 2.4.2 Web Client Flow We should have an OPTIONAL username parameter: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for this user. This is useful for clients where a user is already logged into a 3rd party web site with a specific account, and the client wants the authorization to match the specific user. I think introducing the concept of user identity is more complex than just a username parameter. I agree that it can be useful but we need a more detailed discussion about this before we add it. I agree issues around user identity are complex. Would it help to spin up a separate discussion thread on this one issue? 2.4.2 Web Client Flow Sending an access token as a query parameter is dangerous from a security perspective - these tokens are leaked via referrers and server logs. In previous WRAP discussions, it was felt that we should have a strong recommendation to use the URL fragment. Suggested wording: Client SHOULD send a callback URI with a query fragment, and authorization server MAY reject callback URLs without a fragment for security reasons. Why not require it? I made the assumption that someone had use cases that drove the examples in the spec. I would be OK with requiring it. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on Web Callback Client Flow
On Tue, Apr 6, 2010 at 7:53 AM, David Recordon record...@gmail.com wrote: The web client flow was intended to require either a fragment or SSL (or optionally both). Even with SSL, referrer leaks seem to be a danger (I think https referrers are still sent). Are we worried about this? On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert uid...@google.com wrote: On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Hi Evan, On 4/5/10 4:28 PM, Evan Gilbert uid...@google.com wrote: 2.4.1 Web Callback Flow 2.4.2 Web Client Flow In both flows, the authorization server should be able redirect back to the callback URI without interacting directly with the resource owner if access has already been approved. This is not ruled out in the current language but it could be made cleaner. Suggested rewording - change After receiving an authorization decision from the resource owner, the server redirects the resource owner to the callback URI. to If the client is already approved or denied for access to the protected resource, the authorization service MAY redirect the resource owner to the callback URI immediately. If not, the authorization service SHOULD ask the resource owner for an authorization decision and after receiving the decision redirect the resource owner to the callback URI. I opted for a simpler change: 'After receiving (or establishing via other means) an authorization decision' Sounds great 2.4.1 Web Callback Flow 2.4.2 Web Client Flow We should have an OPTIONAL username parameter: username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for this user. This is useful for clients where a user is already logged into a 3rd party web site with a specific account, and the client wants the authorization to match the specific user. I think introducing the concept of user identity is more complex than just a username parameter. I agree that it can be useful but we need a more detailed discussion about this before we add it. I agree issues around user identity are complex. Would it help to spin up a separate discussion thread on this one issue? 2.4.2 Web Client Flow Sending an access token as a query parameter is dangerous from a security perspective - these tokens are leaked via referrers and server logs. In previous WRAP discussions, it was felt that we should have a strong recommendation to use the URL fragment. Suggested wording: Client SHOULD send a callback URI with a query fragment, and authorization server MAY reject callback URLs without a fragment for security reasons. Why not require it? I made the assumption that someone had use cases that drove the examples in the spec. I would be OK with requiring it. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on Web Callback Client Flow
On Tue, Apr 6, 2010 at 11:15 AM, David Recordon record...@gmail.com wrote: There is potential for leakage if the client then redirects the user to another SSL URL. This doesn't feel like a common pattern and the client would generally be redirecting to a page which they control after receiving the access token. From 15.1.3 of RFC 2616: Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. There are several ways tokens passed on URLs tend to leak. I think I listed them all in the security considerations. [1] If the callback URL points to a page that links to third-party content, the third-party content will get a copy of the URL, including the access token, via the referer header. Search for 'referer' in the browsersec wiki [2] for the gory details. If the callback URL is an open redirector, it might be tricked into sending the access token to an untrusted third-party. If the web server logs requests, the access token will end up in the web server logs. Passing the token on the fragment mitigates all of those risks. Callback URL whitelisting is also important. Time-limited access tokens are a final layer of defense. There are some intrinsic risks here - I'd like to make sure that we treat lightweight javascript clients (no secrets, transient data access, authenticated only by callback URL) different than full-fledged web servers (can keep secrets, permanent data access.) Note that it's pretty easy for a web server to pass an access token down into a javascript widget. So I think there's a clear upgrade path from the one mode to the other. Cheers, Brian [1] http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations [2] http://code.google.com/p/browsersec/wiki/Part1#Hypertext_Transfer_Protocol ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
