You're taking the reading of the cache control semantics too far.
First off, the token introspection response is not covered by the cache semantics specified in 6749. In fact, 7662 specifically states:
The response MAY be cached by the protected resource to improve performance and reduce load on the introspection endpoint, but at the cost of liveness of the information used by the protected resource to make authorization decisions.And there's a big discussion of the tradeoffs of cacheing in section 4. And the RS doesn't ever cache the token itself, but it could cache the introspection results.
As for the text from 6749 you referenced: The client is of course allowed to store the tokens given to it by the AS. If it didn't, OAuth would be kinda pointless, wouldn't it? What the cache control is all about is preventing the HTTP response from the token endpoint from being cached. The token response includes the token, but it is not the token as an entity.
I think we should inherit the discussion and tradeoffs in 7662 section 4 for our token lifetime management (from the RS's perspective) in UMA. Some APIs will want to cache tokens for performance, some will want to check every single time. We should allow both and let API developers keep their eyes open as for the differences.
-- Justin
On 12/31/2016 2:29 PM, Eve Maler wrote:
In our 2016-11-10 telecon, we said:
"Sec 3.4: The RS has the option of using cached RPT status results, so include this in the options (has swimlane implications?). This is also an AS TTL strategy thing (including revocation and disconnected RS scenarios, e.g. IoT scenarios), which we should comment on if we haven't already.
- Add companion security considerations around TTL for RPTs and permissions, since you need to measure risk and risk appetite based on the RS, the resource itself, and even the nature of the policy conditions etc. Without active revocation infrastructure, the risks are higher."
So I poked around the OAuth spec to see if there's similar wording I could align with, and discovered this in Sec 5.1:
"The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache"."
So...I believe this means the client isn't allowed to cache tokens given to it by the AS, and maybe the RS isn't allowed to cache token introspection responses given to it if the token introspection spec follows along in this pattern. But the RS is allowed to cache tokens that the client brings to it because this isn't an AS response, but rather a client request. And if it has locally validated those tokens, it can hang onto the results as long as it wants as well.
I looked a little further, at the OAuth Threat Model spec, and there's potentially some broadly suggestive text in Sec 4.6.6 about both clients and RS's using Cache-Control: private to protect against leakage through HTTP proxies, but nothing more directly relevant.
Some specific questions for people to react to:
- Is my interpretation above about the RS's abilities correct? With an analysis of who can cache what completed, would anyone agree it might be helpful to put the result into the spec as a "Note" observation so others don't have to repeat the exercise and possibly get it wrong?
- Our spec says it "mainly relies on OAuth" for security considerations. Does this mean we must pick up on the prohibition against the AS letting the recipient cache things? I don't think so because it's in the main body of the spec.
- Do we therefore want to add similar wording for the same security reasons OAuth itself has that wording?
- What exactly should our security consideration about TTL of permissions and RPTs say? I think it should cover the circumstances of both local validation and caching. I could use wording similar to what our telecon notes say, but the trick is that the RS doesn't have access to the policy conditions. However, it does have "Adrian clause" rights it may want to apply, so we could mention that.
- In fact, I'm starting to think that a more extended discussion in the Federated Authorization section about this concept -- the fact that the RS retains "edge (local?) authorization" rights -- would be useful to point to from more than one other location in the spec, including this new Security Considerations section.
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/ mailman/listinfo/wg-uma
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma