On Fri, Nov 17, 2017 at 6:39 PM, Malithi Edirisinghe <[email protected]> wrote:
> > > On Fri, Nov 17, 2017 at 6:12 PM, Johann Nallathamby <[email protected]> > wrote: > >> Hi Farasath, >> >> On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed <[email protected]> >> wrote: >> >>> >>> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby <[email protected]> >>> wrote: >>> >>>> Self contained JWT's may get quite large and if we set it as the >>>> default size in the script, for users who are not using self contained JWT >>>> also it is going to consume large space in the database. >>>> >>>> Did we think about storing a hash of the access token? >>>> >>> >>> As pointed out by Johann JWT can grow large with requested claims etc. >>> so changing the column size can happen as soon as the JWT exceeds the >>> defined length, >>> >>> Therefore, We had few discussions offline on options to resolve this. >>> >>> 1. User a different data type like BLOB/TEXT to store the JWT access >>> token and store a hash to improve search. In this approach we will avoid >>> the SQL error, but there will be performance drop for normal UUID based >>> access tokens. >>> >> >> May be we can introduce a config to say whether we need to hash or not. >> >> >>> >>> 2. Not store the self contained access token in the database at all[1]. >>> Since by definition the self contained access token has all the necessary >>> data to validate it we can validate the token on IS during introspection. >>> Ideally, the idea behind the self contained access token is to avoid >>> introspection. But if required we can do it using the presented the JWT >>> itself.(This is how client will validate the access token anyways). >>> Downfall of this approach is that we cannot revoke the token since we >>> don't anyway keep any reference to the issued token. >>> >> >> We can use the "jti" claim of the JWT as the reference and use it to >> manage the token in IS. >> > > So I think you meant that we don't need to persist the self contained > access token at all (even the hash) and use an identifier to reference the > token issued. And that reference will be returned with the JWT as 'jti' > claim. > Yes > > >> >> Regards, >> Johann. >> >> >>> >>> [1] https://www.oauth.com/oauth2-servers/access-tokens/self- >>> encoded-access-tokens/ >>> <https://www.google.com/url?q=https%3A%2F%2Fwww.oauth.com%2Foauth2-servers%2Faccess-tokens%2Fself-encoded-access-tokens%2F&sa=D&sntz=1&usg=AFQjCNF5pHN-sGoIgbANyG1WpbRC-dZfSA> >>> >>> >>> Appreciate your thoughts! >>> >>> >>> >>>> >>>> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Currently, ACCESS_TOKEN column length is defined as 512 [1] which is >>>>>> not enough to store self-contained access token [2]. >>>>>> >>>>>> Shall we increase the column size by default? >>>>>> >>>>>> Thanks >>>>>> Isura. >>>>>> >>>>>> >>>>>> [1] >>>>>> CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN ( >>>>>> TOKEN_ID VARCHAR (255), >>>>>> ACCESS_TOKEN VARCHAR(512), >>>>>> REFRESH_TOKEN VARCHAR(512), >>>>>> CONSUMER_KEY_ID INTEGER, >>>>>> AUTHZ_USER VARCHAR (100), >>>>>> TENANT_ID INTEGER, >>>>>> USER_DOMAIN VARCHAR(50), >>>>>> USER_TYPE VARCHAR (25), >>>>>> GRANT_TYPE VARCHAR (50), >>>>>> TIME_CREATED TIMESTAMP DEFAULT 0, >>>>>> REFRESH_TOKEN_TIME_CREATED TIMESTAMP DEFAULT 0, >>>>>> VALIDITY_PERIOD BIGINT, >>>>>> REFRESH_TOKEN_VALIDITY_PERIOD BIGINT, >>>>>> TOKEN_SCOPE_HASH VARCHAR(32), >>>>>> TOKEN_STATE VARCHAR(25) DEFAULT 'ACTIVE', >>>>>> TOKEN_STATE_ID VARCHAR (128) DEFAULT 'NONE', >>>>>> SUBJECT_IDENTIFIER VARCHAR(255), >>>>>> PRIMARY KEY (TOKEN_ID), >>>>>> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES >>>>>> IDN_OAUTH_CONSUMER_APPS(ID) ON DELETE CASCADE, >>>>>> CONSTRAINT CON_APP_KEY UNIQUE >>>>>> (CONSUMER_KEY_ID,AUTHZ_USER,TENANT_ID,USER_DOMAIN,USER_TYPE, >>>>>> TOKEN_SCOPE_HASH, >>>>>> TOKEN_STATE,TOKEN_STATE_ID) >>>>>> >>>>>> >>>>>> [2] https://wso2.org/jira/browse/IDENTITY-6917 >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Isura Dilhara Karunaratne* >>>>>> Associate Technical Lead | WSO2 >>>>>> Email: [email protected] >>>>>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>>>>> Blog : http://isurad.blogspot.com/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Isura Dilhara Karunaratne* >>>>> Associate Technical Lead | WSO2 >>>>> Email: [email protected] >>>>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>>>> Blog : http://isurad.blogspot.com/ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Johann Dilantha Nallathamby* >>>> Senior Lead Solutions Engineer >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>> >>> >> >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> > > > > -- > > *Malithi Edirisinghe* > Associate Technical Lead > WSO2 Inc. > > Mobile : +94 (0) 718176807 > [email protected] > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
