Assigning role to existing tokens

[m-yazdani]

first of all thanks u so much for sharing your knowledge.
i have a lot of existing token in my oath_access_token table, and as is see from your project roles and authorities are being stored in created token by token creation request. my question is what should i do for my existing tokens ? my user tokens are created at right now when i give some role to my users the created token does not change and what should i do for that?

[d3minem]

@adamzareba - Thanks for sharing this example. I have the similar @m-yazdani question, why do we store the access tokens in the storage? Is it a requirement based on OAuth 2.0 specifications?

In general, I think access_token or refresh_token should not be stored in database. According to Http official RFC-2616 specification, it's a stateless protocol.

HTTP 1.0/2.0

It's clearly visible from official RFCs as well. It is stated:

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks...

and the definition of HTTP/2 says:

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2)... This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

REST

Similarly, we have REST protocol which is also stateless according to it's author - RoyT.Fielding .

Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have sent it again in this request.

So why do we have STICKY SESSIONS around? when access_token comes with expiry time for all OAuth grant types.

• Authorisation Code
• Client Credential
• Implicit
• Password

Note: Before/After the access_token get expired, the refresh_token should be used to request for new access_token. If the refresh_token is also expired, then end user/machine should re-authenticate itself.

After authentication with OAuth, the access_token or jwt token set by authorisation server as the cookie. So every request from client should contain the access_token or jwt token with expiry time. Now we can discuss, the responsibility of checking the access_token or jwt token validity which can be shared between client or auth server.

So do you still think we need database for storing OAuth tokens? Please let me know if I've missed any use case. Storing the tokens in database has very limited scope, such as one of the use case defined by @m-yazdani.