Nightscout - User auth token not accepted?

[skaffen]

I run Nightscout on heroku with the

AUTH_DEFAULT_ROLES denied

setting to keep the site private.

I created a readonly user (roles 'Readable') to allow AutotuneWeb to access the data. However when I supply a tested and valid URL+token to https://autotuneweb.azurewebsites.net,

The remote server returned an error: (401) Unauthorized

is returned. I wondered if the app is stripping off the auth token?

[GrantAdkins]

Yup, have the same issue. Token is definitely valid, but get the same 401 error.

[MarkMpn]

Duplicate of #2, I won't be supporting this for the reasons given in that issue.

[GrantAdkins]

Hi @MarkMpn

Fair enough, I just found the info on the API security requirements (https://github.com/nightscout/cgm-remote-monitor/wiki/API-v1-Security) and it makes sense you don't want to authentication using the API_SECRET but couldn't you authenticate using the Token authentication method mentioned in their API security docs? Specifically, invoking /api/v2/authorization/request/<token>?

Parse the token in that request's response and then use that token in a header Authorization: Bearer <token> for subsequent requests to /api.

I think that would work?

[MarkMpn]

It would work, but there's no way of me knowing that the token you give me is read-only. If you give me a token that gives me write permission, and that token was intercepted or leaked, then someone could start changing settings in your Nightscout database. Depending on the technology you use, that could then be used to automatically change the basal rate settings on your pump, change I:C ratios, set temporary targets etc, the results of which could be disastrous. So in all, not a risk I'm prepared to take.

[GrantAdkins]

The auth response does include what permissions groups that token has. For example:

{ "token": "REDACTED", "sub": "autotune", "permissionGroups": [ [ "*:*:read" ], [] ], "iat": 1616844626, "exp": 1616873426 }

So you could validate the token only has *:*:read and if not, blow away any record of that token and return an error asking for a read token to the user? Or are you worried even asking for tokens is a step too far?

Thanks for the quick replies, btw :)

[MarkMpn]

By the time the token has been sent to me, I figure it's too late and the risk is already there.

[GrantAdkins]

Totally understand your position on this, you need to be comfortable with your exposure. No doubt you appreciate this already but I do want to mention that you're running HTTPS so no parameters could be intercepted between the client and your controller class unless there was a man in the middle attack.

But all good, I'll spin up my own instance to use as I think the risk of turning off NightScout authentication rules to use your service is worse than your concerns about tokens being intercepted. Thanks for your work on this project though! Genuinely much appreciated.

[skaffen]

@GrantAdkins I totally agree with you here. To me the risk of having to open up NIghtscout to the world everytime I use AutotuneWeb, feels far riskier than suppling a read only token. Several times I've forgotten to lock it back down. It's a faff to change the setting in Heroku each time.

That is after all what read only tokens are for. Safe, granular access.

Radical thought here - could AutoTuneWeb be merged into Nightscout? Then the issue is moot.