-
Notifications
You must be signed in to change notification settings - Fork 18
How do we identify apps? #33
Comments
I'd rather say: The problem is that we want to identify apps, i.e., we need a unique identifier for every individual app.
|
|
|
an app is identified so that:
|
When you say "the a problem is that the Origin request header can't be trusted" that suggests a failure to distinguished between bots and web apps. Bots do not use the origin header. Webapps only have the origin header, and nothing else. See the a problem is that the Origin request header can't be trusted. See #12 (comment) If you want to here work on bots -- independent software agents- then can you change the title to " |
@timbl the original title of this Issue was "figure out how to distinguish web apps for the bearer token authorization case". i agree that in "first party" cases where the user has logged directly in to a server/service, and is identified by a browser cookie, the Origin header is appropriate and sufficient (and i don't believe there is any other information that could be trusted in this case). the bearer token case (implemented for some time in NSS and client auth libraries, and being documented in "Various Documentation improvements" #27) is primarily for cases like "i'm using an in-browser newsfeed-like app showing updates, postings, etc from my hundreds of friends and other sources, but i don't want to (or it's impractical to) log in separately to each of my friends' pods and other sources and establish & maintain session cookies with each one". the current solution involves a visible-to-javascript access token to identify the user to resource servers. because this token is visible to javascript (unlike a cookie), it can be trivially shared outside of the browser by the app, including to non-browser agents that could send any Origin header along with the token, and therefore be the user to a resource server but appearing to be using a more privileged app. i believe the scope of this Issue should be for deciding how best to identify these kinds of apps with the same degree of trustability as the Origin header with first-party cookie-based sessions. both #12 and #23 propose solutions for this specific case. bearer token authorization is also useful for the "server-side component of an app is acting on behalf of the logged-in user" and the "bot with its own webid is accessing restricted resources on its own" cases. |
in #23 (comment) @RubenVerborgh suggested that
there are currently two open Issues that propose technical solutions to this problem:
thea problem is that theOrigin
request header can't be trusted (if it is even present) when bearer-type access tokens are presented vs using cookies, because the presenter might not be the user's trusted user-agent (web browser, command-line tool directly under control of the user, etc). this is because an app that generates or possesses a token could pass it to an agent that isn't under the direct control of the user (like server-side code), that is free to set (or omit) any request header to any value, includingOrigin
.therefore, a method other than the
Origin
request header is needed for this case to identify an app to a resource server in a manner that is acceptable and trustable to the user and to the resource owner.The text was updated successfully, but these errors were encountered: