On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt <[email protected]> wrote: > Hi Travis,
Hey there, Torsten. Sorry for the slow reply. Still jet lagged ;-) > > On 26. Sep 2019, at 11:26, Travis Spencer <[email protected]> wrote: > Do others have an opinion about this? https://tools.ietf.org/html/rfc7322#section-3.6 > > * Instead of issuing an expired JWT (or in addition) I think it should > > be valid for the AS to reply with a 201, no content. > Inline with RFC 7662, the AS always provides data to the RS even in case the > introspected access token is expired. Sure, but is that a good line to follow? The client said it accepts application/jwt, but the server returns application/json. This breaks HTTP. (I know that that HTTP allows the server to return a different media type than the one that was requested if there is only one representation of the resource, but this is not the case here.) So, to do this in a way that doesn't break (my understanding of) HTTP, the client would have to accept both application/jwt and application/json. Because the status code isn't helpful in determining which, the body has to parsed based on the content-type response header value. I think this makes it harder on the consumer than it needs to be and undoubtedly slower. > We clarified the intention of this draft due to various feedback (IESG review > and other postings on the list). It is supposed to provide a JWT encoded > introspection response and not a transformed access token. I continue (perhaps out of will, I admit) not to see how what I'm asking for a transformation and not a re-encoding of the same. > The main differences lay in the existence of the “active“ claim and the > different „iat“ values. The addition of the active claim is a change, I admit that. The iat claim could be the same as the original though. > In order to prevent JWT confusion, the JWT shall be restricted to the > originator of the introspection call. In section 5, the draft has this: "The value of the 'aud' claims MUST identify the resource server receiving the token introspection response." By resource server here, does it mean, literally, the caller? RFC 6749 seems to pin that down to one "server" so I think so. If so, this is different from what's commonly used for audience (or at least "common" among my experiences). As defined in the JWT spec (https://tools.ietf.org/html/rfc7519#section-4.1.3), "[t]he 'aud' (audience) claim identifies the recipients that the JWT is intended for....The interpretation of audience values is generally application specific." This divergence is confusing. I didn't notice it on first (or second) read, and highly recommend converging these. I think the JWT definition makes this spec more useful. > This prevents your use case, but how should we distinguish this from access > token replay/abuse? As you say in section 8.1: "such an attack can be prevented like any other token substitution attack by restricting the audience of the JWT." I just think the audience that is defined in this spec is too narrow. Audience is more like a domain than a web service client (e.g., the introspection API client). I see the gateway and the microservices behind it as the same Resource Server with the same audience if they are all in the security domain. I see the gateway as being able to straddle multiple audiences though because it could be fronting multiple clusters of microservices that are in different domains (i.e., have different audiences). This straddling of different domains means the gateway either has a different audience or multiple. > Also, the JWT produced cannot be sender constrained, which even more makes > its use as an access token unadvisable. Sender constrained tokens do provide additional security properties that are desirable in some cases, but they are not the only kind that are advisable. It depends on the situation, right? > In my perception, your proxy transforms the token to make it easier > consumable by the target RS. This is one of the drivers for what I'm advocating: simple API development. > I see two ways to approach it: > > 1) There is a (yet to be specified) function at the AS that transforms an > opaque access token into an JWT-based access token while preserving its > audience and other properties (like sender constraints). The proxy itself > requires authorization to request that functionality but is not an audience. > The access token might even be encrypted for the target RS and be unreadable > for the proxy. This hypothetical spec would vary from this one in what ways exactly? That's not a facetious question, but something I think we should honestly catalog. You listed some ideas below, but I need to think more about these. That gap will help us make informed decisions and relates to Justin's question about the gap to Token Exchange as well. See my concern below about how we fill this gap. > Open: How would one implement sender constrained access tokens in that case? > I’m asking since the receiving RS obviously has no access to the information > from the TLS handshake since TLS termination happens at the proxy (or even in > before the request hits the proxy). The RS would need to get provided with > the cert fingerprint via a trustworthy header, i.e. the RS must be aware of > the fact it sits behind a proxy. This is unfortunately the typical case even with the mTLS draft. This is because SSL is almost never terminated by the AS; in my experience, TLS termination is instead handled by some very fast proxy.[1] In such cases, the proxy will pass the cert through to the AS in some undefined HTTP header with some undefined encoding. The mTLS spec should have defined this IMO, as it prevents interop for a primary use case -- sender constrained tokens. In the case of introspection, I think this verification of the confirmation method is another aid the proxy could provide to the microservice. The proxy climbed the chain as it terminated SSL, fetched CRLs/OCSPs, called LDAP server to get intermediate certs, etc. Verifying the hash of the cert is not hard for it do as well. If the proxy doesn't want to parse the body of the introspection HTTP response though, it will have to forward the cert. The HTTP header and encoding used is undefined, and that is unfortunate for the sake of interop. For proxy auth though, we have the HTTP spec, so that could be leveraged. > 2) If that’s the case, the RS could also process the token introspection > response as received by the proxy. In order to check the audience > restriction, the introspection response would need to contain another claim > containing the original audience claims of the introspected access token. You > could build that on top of draft-ietf-oauth-jwt-introspection-response. What > would it take? This is my concern: we end up with a lot of specs: 1. Introspection RFC 2. JWT introspection RFC 3. Token exchange 4. This hypothetical RFC that profiles #1, #2 and/or #3 Seems overkill. Can't we make more general specs that cover more use cases? If we don't, the cannon will be so extensive that it'll be unpredictable for many. This could impede adoption. [1] I have only come across a situation where the AS terminated SSL one time, and that was because its mutual TLS impl of the AS didn't allow for cert-based auth unless it did. (This wasn't Curity which allows for proxy-based mTLS but some other product.) The customer reluctantly allowed it and only did TLS-based routing in the proxy. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
