shakedmanes
commented
5 years ago Currently Approach Solution:
In access token of type bearer, we can revoke token easily because the resource server will anyway ask for each request the OSpike server if the token is valid and information about it. So according to that, we can let the client decide which type of the access token he want to create (JWT/bearer) and only if he choosing bearer type, he can revoke the token afterwards.
Pros:
- Solving the problem nicely without any weird approach, and supported by the rfc.
- Does not modifies the code and create flaws, only adds feature.
Cons:
- Makes the resource servers to make request to the OSpike server for each API request made (by the clients).
What is Token Revocation?
Token revocation as defined here is a way the client can notify the authorization server that a previously refresh or access token is no longer needed. In that way, the client can perform some sort of 'log-out' mechanism.
Currently Problem Facing:
In access token scenario, the type of the token should be JWT, so the client and resource servers cannot differ if the access token they hold is currently active or revocated (cause JWT access token it self-validated via public key and there's no need to use the token introspection for validating the token).