refresh token expiry time
Both the UK ( https://github.com/OpenBankingUK/read-write-api-docs-pub/blob/v3.1.3-draft1/profiles/read-write-data-api-profile.md#token-expiry-time ) and Australian ( https://consumerdatastandardsaustralia.github.io/standards/#scopes-and-claims ) standards define (different ) ways to pass back the refresh token expiry time.
It may make sense for FAPI to define a standard mechanism?
Comments (17)
-
-
I hadnāt recognised that OBIE and CDS were not aligned. I agree standardising this is a good idea although perhaps this is beyond FAPI as it seems like something various OPs globally have solved in a variety of ways? Any ideas on vendor coverage? Any clear majority?
Regarding the OBIE vs. CDS divergence, I will migrate what was previously a custom claim in Profile Specific to Non-Spec Compliant Changes and link to this thread.
-
reporter Stuart pointed out linkedin uses another slightly different variation:
ā
https://developer.linkedin.com/docs/Refresh-Tokens-with-OAuth-2#
ā
and thereās a thread on this on the connect working group here:
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20190826/thread.html
-
Just adding a footnote here regarding FAPI compared to CDS. The rename of the claim is one element however there appears to be a change in business rule behaviour with respect to if the claim is present when token is not supplied. In FAPI I believe it is specifically ABSENT while in CDS it is āa zero valueā. null != 0 || āā || ā0ā
-
As discussed on call, the two main variations of this Iāve seen are refresh_token_expires_at with an epoch and refresh_token_expires_in with a countdown of seconds. OBIE realms refresh_token_expires_at but the value format (numeric epoch) remains the same. ACDS it is unrealmed but it MUST be provided with a āzero valueā supplied if no refresh token is in use.
Considering fractured adoptions, perhaps at least optional support for both a registered set of refresh_token_expires_at and refresh_token_expires_in could be a starting point?
-
reporter discussed on 16th Oct WG bug call and suggestion was this should be raised up to see if the openid connect WG have any appetite for standardising it.
-
-
assigned issue to
-
assigned issue to
-
Interesting additional note here and raised by another ACDS participant. The
exp
claim at the refresh token introspection endpoint at least within ACDS appears to be the same as itāsrefresh_token_expires_at
. LinkedInās addition ofrefresh_token_expires_in
seems to be an alternative to avoid offering token introspection (which they donāt appear to support).As per RFC7662 it would seem the addition of this claim is only necessary for when introspection endpoints are not mandated within the deployment environment or where the participants want to avoid the need for a call back to retrieve it?
-
Claims are mandated by the RP. Some standard may have an opinion, but people do what the feel necessary and possible.
-
- changed status to open
-
@Tom Jones The challenge I see here is claims with same or very similar names having different interpretations. This makes it challenging environments where implementers are building for multiple standards in a single platform.
-
Itās a fair shout - an IANA registry for clams or a standard for identify the claims as unique resource would be useful however back to an earlier point. knowing where a refreshtoken will expire is a common feature so really it should be an oAuth or connect core respoinsibility to specify it.
-
I donāt think this should be added to the FAPI spec and propose we close.
-
- changed status to resolved
Closing as no activity
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 ā Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment
Would be grand - The standard alternative was to allow the RPās to introspect the refresh token post it being returned, this has been implemented by a couple of vendors.