Hello all,
For anyone who may be interested: MITRE, in support of the U.S. Government, has
developed tailored OAuth and OpenID Connect profiles for use in enterprise
environments. We have leveraged previous standards efforts (e.g. work in the
IETF and in the OpenID Foundation) and have detailed
Do you mean different requests should have the same jti value for better
security?
It is not good that RFC 7662 has chosen "jti" as a property to hold the
identifier for an access/refresh token although the format of introspection
responses is not JWT but just JSON. If the name were, for instance,
> On 2. Mar 2020, at 18:27, Takahiko Kawasaki wrote:
>
> From RFC 7662, Section 2.1
> To prevent token scanning attacks, the endpoint MUST also require some form
> of authorization to access this endpoint, such as client authentication as
> described in OAuth 2.0 [RFC6749] or a separate OAuth
>From RFC 7662, Section 2.1
*To prevent token scanning attacks, the endpoint MUST also require some
form of authorization to access this endpoint, such as client
authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0
access token such as the bearer token described in OAuth 2.0
> Am 02.03.2020 um 17:52 schrieb Takahiko Kawasaki :
>
> The requirement for "jti" described
> in draft-ietf-oauth-jwt-introspection-response-08 is problematic.
I think having different jti values for different requests is a security risk.
smime.p7s
Description: S/MIME cryptographic signature
Hi Torsten,
draft-ietf-oauth-jwt-introspection-response-08 says as follows.
*The "jti" claim is a unique identifier for the access token passed in the
introspection request. This identifier MUST be stable for all
introspection calls for a given access token.*
This requirement expects that the
Hi Taka,
I see, the audience is multi value. In my impression both specs assume a single
value audience.
But I think we can handle this as follows: Since the caller of the
introspection respect is a single RS, the AS first needs to map & check the
resources associated with the underlying acce
Hi Torsten,
For example, if an authorization request includes two "resource" request
parameters like below,
resource=https://host1.example.com/resource1
resource=https://host2.example.com/resource2
RFC 8707 expects that the value of "aud" in an introspection response look
like the following.
"a
Hi Ben,
>>
>>>
>>> I don't think the new semantics for "jti" in the introspection response
>>> are compatible with the RFC 7519 definition. Specifically, we say that
>>> "jti" will be tied to the input access token, but 7519 says that "jti"
>>> has to change when the contents of the JWT change
Hi Filip, Hi Taka,
iat: We might add a structure (e.g. "underlying_access_token") to be able to
convey “iat" for both the underlying access token as well as the JWT-formatted
introspection response to the RS. I’m not really convinced we need to add this
additional complexity since, in my experi
Hi Taka,
> On 1. Mar 2020, at 08:10, Takahiko Kawasaki wrote:
>
> Hello,
>
> I'm wondering if the following conflicts in "JWT Response for OAuth Token
> Introspection" (draft 8) have already been pointed out.
>
> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an
> intro
That sounds like a good addition to a separate document Phil.
ᐧ
On Sun, Mar 1, 2020 at 8:33 AM Phillip Hunt
wrote:
> Why not just require service accounts to use mutually acceptable http
> method of authentication? Eg instead id/password, service acnt client
> could use mtls auth or http basic
Hi Ben,
I saw your question and by coincidence i had just been doing some reading in
RFC7662.
Maybe this helps.
Could you give me a pointer where in the text it says that if "active" is
false, no other claims are present? ("active" only appears three times,
but none of them seem to say this.)
13 matches
Mail list logo
