[OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Hello, hopefully I am using the right email address. Simply put, can this spec be enhanced to clarify "Who can use the introspection endpoint for a refresh token? A resource provider or a client app or both?" RFC7662 clearly mentions that the user of introspection endpoint is a 'protected resourc

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Hi, In additional to Bill's query, the use of the term "protected resource" in the context of RFC7662 is quite confusing. As defined by RFC6749 (which RFC7662 defers to for definition of the terms), the term "protected resource" is defined as an "access-restricted resource" that a client can reque

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Hello Bill, I'm just thinking out loud about possible scenarios for a protected resource here... It may decide to revoke a refresh token if a client application tried to use it instead of an access token when the protected resource is paranoid about security. In order to do that an introspection r

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

I would like to add/clarify a couple of things. All our protected resources share the same logic that uses the introspection endpoint in order to verify whether a token is valid or not. We use the active parameter for that. Although, we additionally check the token_type parameter and its value. If

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

I would expect the AS to invalidate the refresh token in this case, which would not require a refresh token mode nor necessarily any signaling back to the resource. -DW > On Mar 1, 2020, at 12:12 AM, Andrii Deinega wrote: > > Hello Bill, > > I'm just thinking out loud about possible scenario

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

How would the authorization server know who actually uses the introspection endpoint assuming that a protected resource and a client application use the same credentials (client_id and client_secret)? Regards, Andrii On Sun, Mar 1, 2020 at 7:38 PM David Waite wrote: > > I would expect the AS to

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

On Mar 1, 2020, at 10:11 PM, Andrii Deinega wrote: > > How would the authorization server know who actually uses the > introspection endpoint assuming that a protected resource and a client > application use the same credentials (client_id and client_secret)? In the external context, you have a

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Yes, actually the term "protected resource" is awkward. It is the resource server's jog to introspect tokens to protect those protected resources. [image: Ping Identity] Bill Jung Manager, Response Engineering bj...@pingidentity.com w: +

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

The question started when some RPs (client apps) asked that AS allow introspection endpoint to RPs so that RPs can check their refresh token's expiry. If AS allows this, which the spec is not clear about, then AS needs to know if the request is coming from RP or RS so that AS can allow the Access T

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Why would the client need to know the refresh token’s expiry? Can’t they just use the refresh token and see? Either way it’s a single round trip to the AS and the client gets the same answer with the same recovery code path. — Justin > On Mar 4, 2020, at 2:01 PM, Bill Jung > wrote: > > The

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Yep, I agree. But that's just me agreeing with it. Unless the spec clearly says it everybody will throw different ideas and use cases. That's why I want the spec to clarify this. On Wed, Mar 4, 2020, 1:42 PM Justin Richer, wrote: > Why would the client need to know the refresh token’s expiry? Ca

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Justin, Aren’t these things considered as valid concerns? The introspection endpoint allows to introspect a refresh token for its consumers whether they are clients or RSs assuming they were successfully authenticated using one or another way. There are lots of projects which act like OAuth & OI

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Hi Andrii, > On 10. Mar 2020, at 22:11, Andrii Deinega wrote: > > Justin, > > Aren’t these things considered as valid concerns? > > The introspection endpoint allows to introspect a refresh token for > its consumers whether they are clients or RSs assuming they were > successfully authenticate