{"action":"created","issue":{"url":"https://api.github.com/repos/openmhealth/shimmer/issues/28","labels_url":"https://api.github.com/repos/openmhealth/shimmer/issues/28/labels{/name}","comments_url":"https://api.github.com/repos/openmhealth/shimmer/issues/28/comments","events_url":"https://api.github.com/repos/openmhealth/shimmer/issues/28/events","html_url":"https://github.com/openmhealth/shimmer/issues/28","id":109143698,"number":28,"title":"What's the security model of shimmer?","user":{"login":"gcampax","id":876889,"avatar_url":"https://avatars.githubusercontent.com/u/876889?v=3","gravatar_id":"","url":"https://api.github.com/users/gcampax","html_url":"https://github.com/gcampax","followers_url":"https://api.github.com/users/gcampax/followers","following_url":"https://api.github.com/users/gcampax/following{/other_user}","gists_url":"https://api.github.com/users/gcampax/gists{/gist_id}","starred_url":"https://api.github.com/users/gcampax/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gcampax/subscriptions","organizations_url":"https://api.github.com/users/gcampax/orgs","repos_url":"https://api.github.com/users/gcampax/repos","events_url":"https://api.github.com/users/gcampax/events{/privacy}","received_events_url":"https://api.github.com/users/gcampax/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-09-30T17:44:33Z","updated_at":"2015-10-02T13:12:02Z","closed_at":null,"body":"Hello!\r\n\r\nI'm trying out shimmer locally, and I noticed that there seems to be no authorization on the /data request: once a the shim-server has acquired the OAuth access token for a given username, it will happily give out data to anyone who requests it.\r\n\r\nThis is perfectly fine if shimmer is meant to be used behind a closed firewall, so that only the real application server can touch shimmer. But that does not work if shimmer controls the OAuth authorization flow on its own: the user must be able to access the authorize callback with the browser.\r\n\r\nThis is also fine if the username is used as a secret bearer token. But the name username, and the fact it appears in plain in the URL suggests that it is not a secret value, and in the security model of the web I'm afraid it makes it more risky (for example, it becomes visible to Referrer headers).\r\n\r\nSo what's the expected security model? How should I configure shimmer in a way that noone can access data that it does not own in the first place?"},"comment":{"url":"https://api.github.com/repos/openmhealth/shimmer/issues/comments/145016291","html_url":"https://github.com/openmhealth/shimmer/issues/28#issuecomment-145016291","issue_url":"https://api.github.com/repos/openmhealth/shimmer/issues/28","id":145016291,"user":{"login":"emersonf","id":834831,"avatar_url":"https://avatars.githubusercontent.com/u/834831?v=3","gravatar_id":"","url":"https://api.github.com/users/emersonf","html_url":"https://github.com/emersonf","followers_url":"https://api.github.com/users/emersonf/followers","following_url":"https://api.github.com/users/emersonf/following{/other_user}","gists_url":"https://api.github.com/users/emersonf/gists{/gist_id}","starred_url":"https://api.github.com/users/emersonf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/emersonf/subscriptions","organizations_url":"https://api.github.com/users/emersonf/orgs","repos_url":"https://api.github.com/users/emersonf/repos","events_url":"https://api.github.com/users/emersonf/events{/privacy}","received_events_url":"https://api.github.com/users/emersonf/received_events","type":"User","site_admin":false},"created_at":"2015-10-02T13:12:02Z","updated_at":"2015-10-02T13:12:02Z","body":"Ciao Giovanni. \r\n\r\nShimmer is not designed to be exposed on the web, because as you said, there are no authorization checks to get data. The resource server is designed to be run within your own infrastructure, and accessed by your backend, in the same way that you'd deploy a database, an email server, or some other subsystem.\r\n\r\nBut as you said, Shimmer needs to be involved in the OAuth dance with a third-party API. Specifically, \r\n\r\n1. Shimmer needs to provide the URL of the third-party site to send the user to to get an authorization grant, called the *authorization URL*.\r\n  * This authorization URL contains a query parameter called the *redirection URI*, which the third-party will redirect the user's browser to once the user completes the authorization grant.\r\n  * The domain of the redirection URI is controlled by the `callbackUrlBase` property in the YAML configuration.\r\n1. Shimmer needs to handle requests to that redirection URI, to extract the grant and exchange it for an access token.\r\n\r\nre: point 1, the authorization URL is obtained by your application using the `/authorize/{shim}` endpoint. That call isn't initiated by the browser and so doesn't need to be exposed. \r\n\r\nre: point 2, the requests are handled by the `/authorize/{shim}/callback` endpoint and the call is initiated by the browser, so it needs to be reachable. However, it doesn't need to be exposed directly. Since the endpoint location is controlled by the `callbackUrlBase` property in Shimmer, it can be a URL to a proxy or to your application, not necessarily to Shimmer. You then just need to get this request forwarded to Shimmer.\r\n\r\nWe've typically done this using a reverse proxy like [nginx](https://hub.docker.com/_/nginx/). Here's an example configuration:\r\n\r\n```Nginx\r\n# forward redirects from third-party API to the shim server\r\nlocation ~ /authorize/(.+)/callback {\r\n    proxy_set_header Host $host;\r\n    proxy_set_header X-Real-IP $remote_addr;\r\n    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\r\n    proxy_set_header X-Forwarded-Proto $scheme;\r\n\r\n    proxy_pass http://shimmer-resource-server:8083;\r\n}\r\n```\r\n\r\nThis effectively keeps Shimmer inside your infrastructure.\r\n\r\nWe know this design isn't the cleanest or most straightforward. We're currently focusing on making data retrievals more robust and expressive, but in a month or so, we plan to look at the authorization management aspects of Shimmer. That should include making these endpoints more clear, easier to use, improving token management, and possibly securing Shimmer itself using OAuth. If you have any feedback, please let us know. We'll try to keep everyone updated on progress on our [developer forum](https://groups.google.com/forum/#!forum/omh-developers).\r\n\r\nPS. I'll add all this information to the README next week, but feel free to ask any further questions here."}}