Hi Hasanthi, On Fri, Jan 12, 2018 at 2:48 PM, Hasanthi Purnima Dissanayake < [email protected]> 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); > Why do we need a new table here? We already have this relationship between authz_code and access_token in IDN_OAUTH2_AUTHORIZATION_CODE table right? If you want to capture the session data key can't you add it as a column to this table? Why are we instead duplicating 3 fields that are already captured in a different table? > > 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); > I didn't get why we need to store the requested claims. Can you briefly explain the importance of storing them? > > 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); > What is stored in VALUES column? Regards, Johann. > > 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: [email protected] > M :0718407133| http://wso2.com <http://wso2.com/> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile: *+94 77 7776950* LinkedIn: *http://www.linkedin.com/in/johann-nallathamby <http://www.linkedin.com/in/johann-nallathamby>* Medium: *https://medium.com/@johann_nallathamby <https://medium.com/@johann_nallathamby>* Twitter: *@dj_nallaa*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
