Announcement Announcement Module
Collapse
No announcement yet.
Who "refreshes" Authentication instances stored in OAuth2? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Who "refreshes" Authentication instances stored in OAuth2?

    Hi,

    The DefaultTokenServices persists access tokens and their associated OAuth2Authentication instances through the TokenStore.

    Where would be the correct place to verify that the OAuth2Authentication being loaded from the backend is still valid?

    For example, that the associated User's account has not been closed...

    Thanks,
    Pablo

  • #2
    Good question. I think it falls outside the narrow scope of OAuth2, but still a problem that needs to be tackled on the ground (i.e. it's an implementation detail).

    I think it is sensible for Resource Servers to not have any knowledge of user accounts or their authentication. One way to do that would be to have a Resource Server always contact a back end (the Authorization Server or its database) to get the OAUth2Authentication information, but this is not the most general case, and it won't suit a lot of Resource Server implementations (they prefer to decode the token locally).

    The existing SECOAUTH implementations of ResourceServerTokenServices actually always consult the backend store (in memory or JDBC), so it's possible at least for the Authorization Server (which does control the authentication) to keep everything up to date by updating its store. But in the general case not even the Authorization Server knows about changes to underlying user account data, so maybe the best it can do in practice in general is probably to limit the lifetime of tokens and force clients to re-authenticate periodically (not fun for users). A really clever Authorization Server would be able to receive notifications from the authentication source when a user account changes, and revoke all the tokens. Again, not really achievable in the general case (e.g. if the authentication source is Google). Then again, maybe an Authorization Server should always know about changes to user account data that affects its Resource Servers (so the authentication is orthogonal, but the Authorization Server has to store more data than it perhaps wants to).

    It's certainly an interesting debate, and probably worthy of a blog or two. Any opinions?

    If you have any idea about how Spring Security can help, we can certainly try and fold those into features, but we don't want to boil the ocean, and this seems more like an detail for concrete implementations, rather than a framework issue.

    Comment


    • #3
      >>The existing SECOAUTH implementations of ResourceServerTokenServices actually always consult the backend store (in memory or JDBC), so it's possible at least for the Authorization Server (which does control the authentication) to keep everything up to date by updating its store

      I think I will go with something like that. Having the right parts of our system notifying our TokenStore implementation, when we really need authorizations to be revoked, to mark the access_tokens/refresh_tokens related to that user as dirty or stale (or delete them for that matter). This will work for us (though users can "connect" from facebook, we are still the authentication source) on the extreme cases I have in mind (blocking access to spammers, etc)

      Thanks,
      Pablo

      Comment

      Working...
      X