Hi All, The flow is implemented as follows.
Request Object persistance/ clean up task: 1. Request Object comes with the OIDC authorization request asa query param. 2. Store the processes Request Object along with the session data key in a table. 3. When issuing a code or an access token some events will be triggered to notify to the above table to update with the code id or the token id considering the session data key. 4. When revoking a code or a token some events will be triggered notify the table to clean the corresponding raw. 5. In refresh token flow, once the a refresh token is issued an event will be triggered to update the inactive old access token id with the new token id. Thanks, On Fri, Jan 12, 2018 at 9:52 PM, Ayesha Dissanayaka <aye...@wso2.com> wrote: > Hi Hasanthi, > > As discussed offline lets change the schema as in below ER diagram. > > > Further, as we process the Request Object ​while processing the > authentication request, then we can save the requested claim information in > to the DB against session_id. Once, the authentication is completed and > user consent is approved, then we can update the request object entry > identified by the session_id(first entity in above diagram) with a > reference to authorization_code or access_token as generated. > > Because, processing JWT/JWE multiple times,(first when processing > authentication request, then after completing authentication flow and > generating tokens) will be additional cost. > > Thanks! > -Ayesha > > > > On Fri, Jan 12, 2018 at 2:48 PM, Hasanthi Purnima Dissanayake < > hasan...@wso2.com> wrote: > >> Hi All, >> >> >> In this effort we are storing the processed claims from the request >> object [1] against the code or the access token. The persistence of JWT >> will happen when the response comes to the authorization endpoint. >> >> 1. >> >> Authorization request is sent to the authz EP with the request >> object. We are validating the request object in this point. >> 2. >> >> Redirecting to the login page. So in the login page the request >> object is visible as a query parameter in the browser url. >> 3. >> >> Redirecting to the consent page. In the consent page also the request >> object is visible as a query param in the browser url. >> >> Problem : >> >> So if someone rewrite the url in the middle and change the JWT we are >> persisting the modified JWT which is wrong. So the JWT is open for the >> middle man attack. >> >> As a solution we thought of introducing a table schema as follows to >> store the request object. >> >> CREATE TABLE IF NOT EXISTS IDN_OIDC_CODE_TOKEN ( >> >> ID INTEGER NOT NULL AUTO_INCREMENT, >> >> CONSUMER_KEY_ID INTEGER , >> >> CODE_ID VARCHAR(512) , >> >> TOKEN_ID VARCHAR(512) , >> >> SESSION_ID INTEGER, >> >> PRIMARY KEY (ID), >> >> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES IDN_OAUTH_CONSUMER_APPS(ID) ON >> DELETE CASCADE, >> >> FOREIGN KEY (TOKEN_ID) REFERENCES IDN_OAUTH2_ACCESS_TOKEN(TOKEN_ID) ON >> DELETE CASCADE, >> >> FOREIGN KEY (CODE_ID) REFERENCES IDN_OAUTH2_AUTHORIZATION_CODE(CODE_ID) >> ON DELETE CASCADE); >> >> CREATE TABLE IF NOT EXISTS IDN_OIDC_REQ_OBJECT_CLAIMS ( >> >> ID INTEGER NOT NULL AUTO_INCREMENT, >> >> CLAIM_ATTRIBUTE VARCHAR(255) , >> >> ESSENTIAL BOOLEAN , >> >> VALUE VARCHAR(512) , >> >> IS_USERINFO BOOLEAN, >> >> SESSION_ID INTEGER, >> >> PRIMARY KEY (ID); >> >> CREATE TABLE IF NOT EXISTS IDN_OIDC_REQ_OBJECT_CLAIM_VALUES ( >> >> ID INTEGER NOT NULL AUTO_INCREMENT, >> >> REQ_OBJECT_CLAIMS_ID INTEGER , >> >> VALUES VARCHAR(255) , >> >> PRIMARY KEY (ID), >> >> FOREIGN KEY (REQ_OBJECT_CLAIMS_ID) REFERENCES >> IDN_OIDC_REQ_OBJECT_CLAIMS(ID) ON DELETE CASCADE); >> >> CREATE TABLE IF NOT EXISTS IDN_OIDC_REQ_OBJECT_SESSION ( >> >> ID INTEGER NOT NULL AUTO_INCREMENT, >> >> SESSION_DATA_KEY VARCHAR(255), >> >> PRIMARY KEY (ID); >> >> As some databases restrict to use table names exceeding the length of 30 >> I needed to adapt to that when naming the tables. >> >> So we introduced a new temporary table as IDN_OIDC_REQ_OBJECT_SESSION to >> store session data key in a different table. >> >> >> 1. >> >> When the authorization request comes to the authz endpoint >> IDN_OIDC_REQ_OBJECT_SESSION, IDN_OIDC_REQ_OBJECT_CLAIMS and >> IDN_OIDC_REQ_OBJECT_CLAIM_VALUES will be filled with the request >> object details comes with the original authorization request. >> 2. >> >> After the token or code generation, the corresponding row of the >> IDN_OIDC_REQ_OBJECT_SESSION will be removed and the table >> IDN_OIDC_CODE_TOKEN will be updated accordingly. So this will allow us to >> prevent storing the modified JWT in the db layer. >> 3. >> >> There will be events for token revoke/delete and refresh flows to >> update the tables accordingly. >> >> >> Any suggestion or feedback is highly appreciated. >> >> [1] http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests >> >> >> -- >> >> Hasanthi Dissanayake >> >> Senior Software Engineer | WSO2 >> >> E: hasan...@wso2.com >> M :0718407133| http://wso2.com <http://wso2.com/> >> > > > > -- > *Ayesha Dissanayaka* > Senior Software Engineer, > WSO2, Inc : http://wso2.com > <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> > 20, Palm grove Avenue, Colombo > <https://maps.google.com/?q=20,+Palm+grove+Avenue,+Colombo&entry=gmail&source=g> > 3 > E-Mail: aye...@wso2.com <ayshsa...@gmail.com> > -- Hasanthi Dissanayake Senior Software Engineer | WSO2 E: hasan...@wso2.com M :0718407133| http://wso2.com <http://wso2.com/>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
