[
https://issues.apache.org/jira/browse/CXF-5180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730685#comment-13730685
]
Sergey Beryozkin commented on CXF-5180:
---------------------------------------
Hi Thorsten
Another interesting issue...
I've been thinking for a while if we need to have some explicit support for
dealing with refresh tokens and I was not sure as the runtime itself only
facilitates the refresh token requests and reporting a new AT and RT back.
Few questions:
- How do you plan to handle pre-emptive client refresh tokens requests,
example, if the client has checked locally that its AT has expired, it would
issue a RT request immediately instead of losing the round-trip with the AT
expected to be rejected, where is that RefreshToken at this moment of time,
while that expired AT is still around ?
- Token revocation (in 3.0.0 SNAPSHOT), the client itself requests a token
revocation, and it can be a RT that needs to be revoked. If we remove RT, then
all ATs linked to the removed RT also have to go.
I think in both cases RT needs to link to AT(s). When a refresh token grant is
coming, the existing AT which is still possibly valid has to be invalidated,
and possibly removed, and the existing RT may have to be recycled most likely
to get a new RT value returned alongside a new AT. In the RT token revocation
request it is also the case (ATs are affected).
Basically, having a RefreshToken model type is a good idea :-) I wonder though
if it can be enhanced a bit, specifically, should it have a List of String
field pointing to AT or ATs which can be refreshed with it ?
> Adding RefreshToken as token type
> ---------------------------------
>
> Key: CXF-5180
> URL: https://issues.apache.org/jira/browse/CXF-5180
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS Security
> Affects Versions: 2.7.6
> Reporter: Thorsten Hoeger
> Priority: Minor
> Labels: OAuth2
> Attachments: 0001-adding-RefreshToken-type.patch
>
>
> It may be useful to have a dedicated RefreshToken class (subclassing
> ServerAccessToken) to represent the generated refresh token. This allows
> implementors to drop the BearerAccessToken on expiry and persist the
> RefreshToken until used by the client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
