- changed milestone to 3rd Implementers Draft
Add requirement for clients to verify scope value returned from the token endpoint
In part 1 we don't have authorization request and response signing and therefore as we note in the security considerations "request tampering and parameter injection are possible".
However we do require the AS to return the scopes granted from the token endpoint. We currently don't require the Client to do anything with those returned scopes.
I suggest we add a requirement for the Client to check the returned scope as this can give extra protection to this profile. For example if a "man in the browser" replaced the scope
value in the authorization request, the Client would still be able to detect this when retrieving the access token.
This isn't a problem for part 2
Comments (13)
-
reporter -
-
assigned issue to
In part 1 we don't have authorization request and response signing and therefore as we note in the security considerations "request tampering and parameter injection are possible".
However we do require the AS to return the scopes granted from the token endpoint. We currently don't require the Client to do anything with those returned scopes.
I suggest we add a requirement for the Client to check the returned scope as this can give extra protection to this profile. For example if a "man in the browser" replaced the
scope
value in the authorization request, the Client would still be able to detect this when retrieving the access token.This isn't a problem for part 2
-
assigned issue to
-
- changed status to open
Need to check if it impacts Part 2.
-
reporter Added requirement to part 1. Then check with WG if it makes sense to keep it or downgrade it in part 2.
-
reporter So, I had a think about this and I’m not sure how to word it.
Should we say that the client should just check the scopes are what it expects?
Or should we be explicit and explain the attack - i.e. that through tampering the scope was switched, therefore the client should verify it has only received the scope it asked for.
-
reporter We discussed this and decided that the there are valid use cases for the AS to return extra scopes, e.g.
- The AS breaks out a “meta scope” to fine-grained scopes, so: “accounts.all” becomes “accounts.read” and “accounts.write”, or
- The AS grants access to accounts held at multiple Resource Servers that need different scope representations
There are also valid use-cases for the AS returning less scopes than requested (e.g. when the user chooses so)
Because of this we will go with some fairly vague wording requiring that the client check the scope is what it expects.
However we discussed having some more prescriptive tests in the conformance suite which would expect the client to detect when unexpected scope was returned from the token endpoint.
-
reporter -
reporter - changed status to resolved
-
- changed component to Part 1: Baseline
-
- changed component to FAPI 1 - Part 1: Baseline
-
- changed component to FAPI 1 – Part 1: Baseline
-
- changed component to FAPI 1 – Baseline
-
- changed component to FAPI 1: Baseline
- Log in to comment