Refresh tokens are also used by public clients, e.g. native apps. OIDC allows
to acquire a new id token from a refresh token as well. Note: this does not
mean a fresh authentication but a refreshed id token containing the data of the
original authentication transaction.
Am 24. August 2015
You don't need to put an expiration on the refresh token. You get to see that
refresh token every 5 minutes anyway. If you ever want to force the client to
re-auth just use policy on the AS. Nothing will be broken with what you are
doing though.
On Friday, August 28, 2015 7:21 AM,
I'm sorry to introduce a common topic.
As John has suggested, I'm going to design that
* An access token should be short lived e.g. 5 minutes (not to hit the AS
to verify the token or 1 hour (to hit the AS to verify the token). I'm
inclined to 5 minutes for stateless architecture of RSs.
* A
One viable method for detecting “inactivity for one month” would be to have a
one month expiration on the refresh token, but reset that counter every time
the refresh token is used to get a new access token. You can do this by
manipulating the expiration of the token object itself on your
This is all contextual to the application. In some situations I want to
immediately force re-authentication for all transactions above X$ such
as banking applications. In some situations I want a permanent refresh
token, like for Twitter like social applications. etc...etc...
- Jim Manico
Again, I would state that this is all contextual to the application
being built - which is why the RFC never gives specific times other than
short lived or long lived. I would suggest giving a series of
recommendations relative to a few different risk profiles (low risk,
social media, banking,
I stand corrected, the RFC does give specific time recommendations such
as 10 minutes authorization code recommendation here
https://tools.ietf.org/html/rfc6749#section-4.1.2 but I think my overall
point is still valid. :)
Aloha,
Jim
On 8/28/15 11:36 AM, Jim Manico wrote:
Again, I would
+1 for John's suggestion.
Why force users to re-authenticate after an arbitrary 30-day window?
On Fri, Aug 28, 2015 at 1:41 PM John Bradley ve7...@ve7jtb.com wrote:
I would use a 5 min AT and roll the refresh token per
https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that
I would use a 5 min AT and roll the refresh token per
https://tools.ietf.org/html/rfc6749#page-47
https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that is
what you want for a inactivity timeout after which the user must authenticate
again. The user can always revoke the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Proof-of-Possession Key Semantics for JSON Web Tokens
(JWTs)
Authors : Michael B.
Proof-of-Possession Key Semantics for JWTs draft -04 addresses the remaining
working group comments received - both a few leftover WGLC comments and
comments received during IETF 93 in Praguehttp://www.ietf.org/meeting/93/.
The changes were:
* Allowed the use of jwk for symmetric keys
This was added at the end of Section 3.2 in
-04http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04.
Thanks again for the practical feedback, Brian!
-- Mike
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent:
Thanks again for your detailed review, Nat. The remainder of the issues you
raised are addressed in the -04
drafthttp://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04.
Replies are inline prefixed by Mike …
From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Tuesday, August 18,
13 matches
Mail list logo
