0

Flow is something like this:

  1. We have an oauth app registered with specific resource ids listed, so this app has access to those
  2. After some time there is a need to add another resource id, as we are extending features of our client app
  3. From time to time client app is doing refreshing of token, its either due to errors or access_token expiration.
  4. Using check_token on new access_token gives us old set of resource ids. Seems its taken from some cache or old token itself.

Question: Shouldn't refresh token refresh also resource ids? Is this againts oauth rfc( couldnt find anything about this particular case in it )?

We ofcourse could revoke all tokens for oauth app, but that would require all our users to log in again which we want to avoid.

Im not sure if its related with spring cloud security or rather oAuth itself. C

Cœur
  • 37,241
  • 25
  • 195
  • 267
hi_my_name_is
  • 4,894
  • 3
  • 34
  • 50

1 Answers1

1

This answers assumes that your resource identifiers are equivalent to what OAuth2 describes as scopes as from your description their purpose seems very similar - constrain the reach of the access token.

When issuing an access token refresh request the specification states that you can include a scope parameter, however:

The scope of the access request as described by Section 3.3. The requested scope MUST NOT include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner.

Additionally, as part of the response a new refresh token could be issued, but again:

The authorization server MAY issue a new refresh token (...) If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the request.

(emphasis is mine, section 6. of the specification)

This means that, per the specification, automatically adding new scopes/resources to an access token is not compliant. However, you don't need to logout the users, you should only need to request the resource owner consent for the new scopes.

Again, this is what the specification states about scopes which does seem to match your usage scenario. However, there are some scenarios where this would not apply so strictly or end up not having a real impact. If a single organization controls the authorization server and client application it can decide that some application enjoy what's sometime known as administrative consent which is basically the resource owner isn't asked for explicit consent because this is a trusted application. In these cases, you could increase scopes/resources without any type of user intervention.

Community
  • 1
  • 1
João Angelo
  • 56,552
  • 12
  • 145
  • 147
  • resources here are just applications (protected by oauth2 ) to which user will have access after log in. As I understand scopes - they give user a clue which personal data those apps will use on his behalf. I dont want to fetch some data behind their back after initial approval, I just want to add more features for an user to interact with an app. – hi_my_name_is Oct 26 '16 at 10:47
  • If your resources do not represent actual data associated to a user are you including them in the tokens just so that you don't have to query them from another place when tokens are processed? If so, I would consider moving them to outside of the token itself. – João Angelo Oct 26 '16 at 10:52