Update:
Table structure will be updated as follows,
IDN_OAUTH2_ACCESS_TOKEN (
TOKEN_ID VARCHAR (255),
ACCESS_TOKEN VARCHAR(2048),
REFRESH_TOKEN VARCHAR(2048),
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 NOT NULL DEFAULT CURRENT_TIMESTAMP,
REFRESH_TOKEN_TIME_CREATED TIMESTAMP NOT NULL DEFAULT
CURRENT_TIMESTAMP,
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),
ACCESS_TOKEN_HASH VARCHAR(512),
REFRESH_TOKEN_HASH VARCHAR(512),
IDP_ID INTEGER,
*TOKEN_BINDING_REF VARCHAR(32) DEFAULT 'NONE',*
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,IDP_ID, *TOKEN_BINDING_REF*)
)
// New Table
IDN_OAUTH2_ACCESS_TOKEN_BINDING (
TOKEN_ID VARCHAR (255),
TOKEN_BINDING_TYPE VARCHAR (32),
TOKEN_BINDING_REF VARCHAR (32),
TOKEN_BINDING_VALUE VARCHAR (1024),
TENANT_ID INTEGER DEFAULT -1,
PRIMARY KEY (TOKEN_ID),
FOREIGN KEY (TOKEN_ID) REFERENCES
IDN_OAUTH2_ACCESS_TOKEN(TOKEN_ID) ON DELETE CASCADE
)
Thanks,
Thanuja
On Thu, Sep 5, 2019 at 12:41 PM Thanuja Jayasinghe <[email protected]> wrote:
> Hi Hasintha,
>
> We are going to introduce the capability to bind the token to an external
> attribute as a part of this feature. So the updated schemas will be as
> follows,
>
> IDN_OAUTH2_ACCESS_TOKEN (
> TOKEN_ID VARCHAR (255),
> ACCESS_TOKEN VARCHAR(2048),
> REFRESH_TOKEN VARCHAR(2048),
> 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 NOT NULL DEFAULT CURRENT_TIMESTAMP,
> REFRESH_TOKEN_TIME_CREATED TIMESTAMP NOT NULL DEFAULT
> CURRENT_TIMESTAMP,
> 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),
> ACCESS_TOKEN_HASH VARCHAR(512),
> REFRESH_TOKEN_HASH VARCHAR(512),
> IDP_ID INTEGER,
> *TOKEN_BINDING_HASH VARCHAR(255) DEFAULT 'NONE',*
> 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,IDP_ID, *TOKEN_BIND_HASH*)
> )
>
> *// New Table*
> IDN_OAUTH2_ACCESS_TOKEN_BINDING (
> TOKEN_ID VARCHAR (255),
> TOKEN_BINDING VARCHAR (1024),
> TENANT_ID INTEGER DEFAULT -1,
> PRIMARY KEY (TOKEN_ID),
> FOREIGN KEY (TOKEN_ID) REFERENCES
> IDN_OAUTH2_ACCESS_TOKEN(TOKEN_ID) ON DELETE CASCADE
> )
>
> So with this implementation, each new binding will receive a new access
> token.
>
> In the user portal case, a new cookie will be created for each new browser
> instance and cookie value will be stored in
> the IDN_OAUTH2_ACCESS_TOKEN_BINDING table. Hash of this value will be added
> to IDN_OAUTH2_ACCESS_TOKEN table, creating a new access token for each new
> browser instance.
>
> Existing behavior also preserved when there are no token bindings provided.
>
> Thanks,
> Thanuja
>
> On Tue, Sep 3, 2019 at 12:19 PM Hasintha Indrajee <[email protected]>
> wrote:
>
>> Hi Thanuja,
>>
>> I have few questions on this.
>>
>> How are we going to bind the token to the cookie (Is this a new entry to
>> a table) ? Is this an existing cookie (may be commonAuth ID) or a new
>> cookie ?. Furthermore, How are we going to handle the scenario where the
>> same user logs in from multiple browsers ? Are we going to have multiple
>> active tokens for same client, user with random scopes ? Or are we just
>> revoking the old token if the same scopes are being used ?.
>>
>> Or else do we have the facility to have multiple active tokens for the
>> same user, application with same scopes in latest IS versions ?
>>
>> On Mon, Sep 2, 2019 at 3:56 PM Thanuja Jayasinghe <[email protected]>
>> wrote:
>>
>>> Hi All,
>>>
>>> With the introduction of new IAM portal applications, there is a
>>> requirement to provide additional security measures to secure these SPAs.
>>> We have already implemented the OAuth2 authorization code flow(public
>>> client) with PKCE for these applications and with this feature, it will be
>>> possible to bind the access token to the browser instance. So, an
>>> additional security measure will be enforced as the combination of the
>>> access token and browser token(cookie) validated while accessing the IS
>>> APIs.
>>> Support for configuring this option using OAuth2 application
>>> configuration and browser token persistence will be added as well.
>>>
>>> Updated request/response flow is as follows,
>>> [image: Blank Diagram (1).png]
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Technical Lead
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891
>>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453
>>
>>
>
> --
> *Thanuja Lakmal*
> Technical Lead
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891
>
--
*Thanuja Lakmal*
Technical Lead
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
