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 <hasin...@wso2.com> 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 <than...@wso2.com>
> 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
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
