Saving Access Tokens in Separate Tables

You can configure the Identity Server instances to store access tokens in different tables according to their user store domain. This is referred to as user token partitioning and it ensures better security when there are multiple user stores configured in the system. For information on configuring user stores other than the default one, see Configuring Secondary User Stores.

To enable user token partitioning, you should change the <EnableAssertions> and <AccessTokenPartitioning> elements in the <IS_HOME>/repository/conf/identity/identity.xml file. A brief description of each element is given below:

<EnableAssertions>
        <UserName>false</UserName>
</EnableAssertions>

<EnableAccessTokenPartitioning>true</EnableAccessTokenPartitioning>

<AccessTokenPartitioningDomains>A:FOO.COM, B:BAR.COM</AccessTokenPartitioningDomains>

<!-- Assertions can be used to embedd parameters into access token.-->
<EnableAssertions>
     <UserName>true</UserName>
</EnableAssertions>

<!-- This should be set to true when using multiple user stores and keys should saved into different tables according to the user store. By default all the application keys are saved in to the same table. UserName Assertion should be 'true' to use this.-->
<AccessTokenPartitioning>
     <EnableAccessTokenPartitioning>true</EnableAccessTokenPartitioning>
     <!-- user store domain names and mappings to new table names. eg: if you provide 'A:foo.com', foo.com should be the user store domain   
     name and 'A' represent the relavant mapping of token storing table, i.e. tokens relevant to the users comming from foo.com user store     
     will be added to a table called IDN_OAUTH2_ACCESS_TOKEN_A. --> 
     <AccessTokenPartitioningDomains>A:foo.com, B:bar.com</AccessTokenPartitioningDomains>
</AccessTokenPartitioning>

Table creation

Once you configure the file for enable access token partitioning, you can create separate tables to store access tokens. These tables should be created in the database which is pointed in <DataSource> element under <JDBCPersistenceManager> in the identity.xml.

Since the IDN_OAUTH2_ACCESS_TOKEN_SCOPE has a foreign key reference to the IDN_OAUTH2_ACCESS_TOKEN table, when using access token partitioning feature, not only IDN_OAUTH2_ACCESS_TOKEN but also IDN_OAUTH2_ACCESS_TOKEN_SCOPE table should be created per each domain mapping configured in <AccessTokenPartitioningDomains> element.

Suppose, for the user store domain 'foo.com' it has defined the mapping as 'A', then it is needed to create IDN_OAUTH2_ACCESS_TOKEN_A table and IDN_OAUTH2_ACCESS_TOKEN_SCOPE_A table. Refer below example for the mysql script which creates two tables, indexes and relevant constraints:

CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN_A (
            TOKEN_ID VARCHAR (255),
            ACCESS_TOKEN VARCHAR(255),
            REFRESH_TOKEN VARCHAR(255),
            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),
            PRIMARY KEY (TOKEN_ID),
            FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES IDN_OAUTH_CONSUMER_APPS(ID) ON DELETE CASCADE,
            CONSTRAINT CON_APP_KEY_A UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TENANT_ID,USER_DOMAIN,USER_TYPE,TOKEN_SCOPE_HASH,
                                           TOKEN_STATE,TOKEN_STATE_ID)
)ENGINE INNODB;

CREATE INDEX IDX_AT_CK_AU_A ON IDN_OAUTH2_ACCESS_TOKEN_A(CONSUMER_KEY_ID, AUTHZ_USER, TOKEN_STATE, USER_TYPE);

CREATE INDEX IDX_TC_A ON IDN_OAUTH2_ACCESS_TOKEN_A(TIME_CREATED);

CREATE INDEX IDX_AT_A ON IDN_OAUTH2_ACCESS_TOKEN_A(ACCESS_TOKEN);


CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN_SCOPE_A (
            TOKEN_ID VARCHAR (255),
            TOKEN_SCOPE VARCHAR (60),
            TENANT_ID INTEGER DEFAULT -1,
            PRIMARY KEY (TOKEN_ID, TOKEN_SCOPE),
            FOREIGN KEY (TOKEN_ID) REFERENCES IDN_OAUTH2_ACCESS_TOKEN_A(TOKEN_ID) ON DELETE CASCADE
)ENGINE INNODB;

If you are using any other database server, you can use the sql script related to your database server, from sql scripts located at <IS_HOME>/dbscripts/identity/directory. These scripts contains all the tables related to identity data (not specific to this feature). You need to extract queries creating detault IDN_OAUTH2_ACCESS_TOKEN table and IDN_OAUTH2_ACCESS_TOKEN_SCOPE tables and indexes and relevant constraints. Then update table names of two tables, relavent indexes, and relevant constraints to append user store domain mapping as in the above example.

Limitations

• Since the user store to table mapping is configured as a static mapping in identity.xml, this feature cannot used if you have more user stores getting created at runtime.
• All tenants use the same mapping configured as per above configurations, it cannot define mappings differenly for each tenants.