You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Sergey Beryozkin (JIRA)" <ji...@apache.org> on 2013/08/06 14:06:48 UTC

[jira] [Commented] (CXF-5180) Adding RefreshToken as token type

    [ 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