Re: [Architecture] Binding access token to the browser for new IAM Portal Applications
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 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 > 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 >> wrote: >> >>> Hi All, >>> >>> With the introduction of new IAM
Re: [Architecture] Binding access token to the browser for new IAM Portal Applications
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 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 > 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
Re: [Architecture] Binding access token to the browser for new IAM Portal Applications
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 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
