Currently in the IDN_OAUTH2_ACCESS_TOKEN table, we store the time of token
generation in TIME_CREATED column in human readable date time format.
Therefore at the time of token generation, we'll have to get the current
timestamp and store it in another column and also add the VALIDITY_PERIOD
to that and store in another column, which would be the expiry timestamp.

If we are doing above, the performance of the responses sent by the Token
Introspection endpoint can also be improved. It sends the iat and exp
values doing the calculation.

{"scope":"openid","active":true,"token_type":"Bearer","exp":1526916282,"iat":1526912682
.......

This way there won't be a calculation in the Token Introspection responses,
where it can directly send the values stored in the data table.


On Mon, May 21, 2018 at 7:46 PM Rushmin Fernando <[email protected]> wrote:

> Hi Devs,
>
> Right now it is the validity period which is getting stored along with the
> tokens.
>
> So in order to expire a token, a calculation is needed during expiry tasks.
>
> When there a lot of tokens, this becomes a bottleneck since the database
> indexes are not applicable.
>
> But if the expiry timestamps are stored in the database, during the expiry
> tasks calculations are not needed and therefore the indexes are applicable.
> This should significantly improve the task execution time.
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>
> mobile : +94775615183
>
>
>

-- 

Tharindu Edirisinghe
Associate Technical Lead | WSO2 Inc
Platform Security Team
Blog : http://tharindue.blogspot.com
mobile : +94 775181586
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to