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 <than...@wso2.com> 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 <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 > -- *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