Loopback-next: Authorize interceptor should return 403 HTTP status

[InvictusMB]

Authentication component returns 401 errors, authorization component should return 403 errors.
See 403 status definition.

Offending lines:
https://github.com/strongloop/loopback-next/blob/b01bb1154346f8dd2786a13e21e291dc52ca35e1/packages/authorization/src/authorize-interceptor.ts#L106

https://github.com/strongloop/loopback-next/blob/b01bb1154346f8dd2786a13e21e291dc52ca35e1/packages/authorization/src/authorize-interceptor.ts#L121

[dougal83]

I'm not sure the issue is entirely black and white as you could have been granted authorisation yet your access token could be stale. Re-authentication would be applicable in this case. Open for debate though, thank you for starting the discussion!

[raymondfeng]

I think we can address this issue as follows:

1. Extend AuthorizationOptions to include a defaultStatusCodeForDeny. If not specified, use 403.

2. Honor options.defaultStatusCodeForDeny in https://github.com/strongloop/loopback-next/blob/b01bb1154346f8dd2786a13e21e291dc52ca35e1/packages/authorization/src/authorize-interceptor.ts#L106.

@InvictusMB Are you interested in contributing a patch?

[InvictusMB]

@dougal83 Could you provide an example scenario?
The way I understand it, when you reach the authorizer you either had a valid token or no token at all. A stale token would have errored out on authentication step.

[dougal83]

@dougal83 Could you provide an example scenario?
The way I understand it, when you reach the authorizer you either had a valid token or no token at all. A stale token would have errored out on authentication step.

Sure, it's possible to have stale tokens say for jwt whereby you can have out of date claims. Say you login to two devices and you update your jwt token on one device and your claims are up to date as expected. However depending on how you handle refreshing tokens, the second device with stale claims can make a call to a resource and not include the updated claims (say additional claims/scopes). The call the second device makes could prompt a refresh of the jwt and a further call after the re-authentication process would result in access, which would satisfy 401. It's a very narrow scenario granted but within the grey area.

It's really up to you, @raymondfeng makes a good suggestion above.

[InvictusMB]

@dougal83 I agree with @raymondfeng's suggestion. However I am hesitant to have more knobs and handles to play with. Also if there was a global option I would be tempted to ask for an overload option on a per resource basis.
I read your scenario as follows: we ask the client to refresh a jwt token whenever he does not pass the authorization. I've worked with services which behaved like that and it was far from pleasant. Precisely because they would send a client into a refresh token loop unless handled with extra care.

I would argue then that 403 should be the default response and the config option could be an escape hatch for situations as described where a false 401 is less harmful than a false 403.

[dougal83]

@InvictusMB Loopback is constantly being developed so as refinements come in then please do get involved in the discussions. There are some issues discussing refresh token behaviour that might be of interest to you? Have a search and see if the discussion looks promising or you have an alternative approach to suggest. I'm interested in this area so I'd be happy to get involved in discussion too.

[InvictusMB]

@dougal83 The unpleasantness that I referred to is actually out of scope of LB4 and server side implementation of token refresh. It emerges on the client side. It is one of the reasons I've created this issue in the first place.
For a client there is just no graceful way to handle a false 401.
Imagine a scenario:

1. I am a client and I have a valid token.
2. I ask for a resource I'm not supposed to see at all and get 401.
3. I check my token and it has not expired, so I refresh it just in case and goto 1.

I am in infinite loop now. If I impose a limit, say 3 attempts, then after reaching it I have to discard the token and log the user out. So now I have a false forceful logout only to compensate for false 403 in a rare case when a client gets elevated permissions in between the token refreshes.

Now that I've given it a bit more thought I insist on my original statement even more. Authorization layer should always error out 403. If the scenario you've mentioned is important, it should be the responsibility of Authentication layer to track down stale tokens and return 401s.