[mitreid-connect] Revoke Consent keeps Refresh Tokens [I]

Thu Mar 23 13:11:48 EDT 2017

Good, glad we agree, just wanted to make sure ;)

The problem are the grants. As far as understood it so far, the grants are the approved sites, correct?

Now if you use a refresh token to get a new access token, this new access token is not linked to the approved site, it is only linked to the refresh token. This means I can't figure out which access token is linked to which approved site aka approved Grant and remove it.

-- Dominik

-----Original Message-----
From: Justin Richer [jricher at mit.edu<mailto:jricher at mit.edu>]
Sent: Monday, March 20, 2017 01:26 PM W. Europe Standard Time
To: Dominik Schmich; mitreid-connect
Subject: Re: [mitreid-connect] Revoke Consent keeps Refresh Tokens [I]

Right, that's exactly what I'm saying -- present the user with the right model through the UI, allowing them to clear tokens and grants in one go instead of (or in addition to) separating them.

 -- Justin

On 3/18/2017 2:56 PM, Dominik Schmich wrote:

Classification: For internal use only
The thing with the UI is, we don’t use it for the end users, which provide the consent. We think it is too much information for them and they would be confused. We created an own page, similar to the “grant access page”, just showing the already granted applications and their scopes. This is the level we think the end user can handle.

On the other side, for developers using mitre, the current webpages are good to see a more detailed view on what’s going on, how many tokens are active, etc.

Coming back to the original behavioral thoughts. I would as EndUser expect, if I revoke the access for an application, it is immediately revoked for all its instances. Therefore I would be confused, if there would still an application being able to access my data/functionality through those “disconnected refresh tokens”. On top of this, if the OAuth2 Server Provider decides to not let the Refresh Tokens time out, those would never be deleted and the applications has access without the user being able to stop it.

If it fits into the thoughts behind the Approved Sites or not I can’t tell. But what I think we need is the connection between the EndUser and the Application which is the consent. As long as the consent is valid, any token can still be used. As soon as the consent is removed, all the tokens need to be removed as well. This more or less results into the connection of any token to the consent, right?

Beste Grüße / Kind regards,
Dominik Schmich

____________________________________________________

[imap://jricher@imap.exchange.mit.edu:993/fetch%3EUID%3E/Projects/MITREid%3E1960?header=quotebody&part=1.2&filename=image001.png]

Dominik Schmich
Assistant Vice President | Solution Architect

Deutsche Bank AG
COO PW&CC Technology, Strategy & Architecture
Alfred-Herrhausen-Allee 16-24, 65760 Eschborn, Germany
Tel. +49 69 910-60543
Mobile +49 1723700665
Email dominik.schmich at db.com<mailto:dominik.schmich at db.com>

[imap://jricher@imap.exchange.mit.edu:993/fetch%3EUID%3E/Projects/MITREid%3E1960?header=quotebody&part=1.3&filename=image002.png]<https://api-open.db.com/>

From: Justin Richer [mailto:jricher at mit.edu]
Sent: Montag, 13. März 2017 19:03
To: Dominik Schmich <dominik.schmich at db.com><mailto:dominik.schmich at db.com>; mitreid-connect <mitreid-connect at mit.edu><mailto:mitreid-connect at mit.edu>
Subject: Re: [mitreid-connect] Revoke Consent keeps Refresh Tokens [I]

I think this is a mismatch between the mental model you have when looking at the software, and the mental model that drove the (current) data structure. When we built this originally, the "approved site" item was attached to tokens as they were created, whether they were approved by a user or whitelisted. This morphed into something that was more like a "remembered grant", where the user's explicit authorization decision was remembered and that was attached to the token.

I'm not saying that your interpretation is incorrect, mind you -- and in fact I think that it's a potentially clearer model. However, I think that we should perhaps address this in the UI instead of the data model. So instead of having separate pages for tokens and grants, as we have today, perhaps a single page for revoking a client's access in both ways. This would more cleanly take care of the non-remembered but permanent refresh tokens and put them at the same level as the remembered grants.

Personally, I think this would be a cleaner way of handling the disconnect than propagating the ApprovedSite link through to the refresh token (and downstream), but I'm open to other suggestions.

 -- Justin
On 3/10/2017 3:01 AM, Dominik Schmich wrote:

Classification: For internal use only
Hi everyone,

I have a little question regarding the Approved Site revocation behavior.

Here is what I did see on the Database Tables:

-          Access Tokens are tied to Approved Sites via the database field ”approved_site_id”.

-          Refresh Tokens are tied to Access Tokens  via the database field “refresh_token_id”.

Now if you remove an Approved Site the method “DefaultApprovedSiteService.remove()” is used. This will get all access tokens, remove all associated refresh tokens and then delete the access token. In the end it removes the Approved Site. This is exactly the behavior I did expect.

This behavior changes once the Refresh Token was used the first time. With the usage, the “DefaultOAuth2ProviderTokenService.refreshAccessToken()” is used. This creates a new AccessToken and re-links the new Access Token with the old Refresh Token via “token.setRefreshToken()”. Which is correct. What I’m missing is the “token.setApprovedSite()” to the new Access Token, which should only be done, if the site is still approved. Due to this not linking, the Refresh & Access Tokens stay in the system until the expire and do not get deleted by “DefaultApprovedSiteService.remove()”. Is this a bug?

What I additionally thought of but didn’t verify is the following scenario: What if there are Refresh & Access Tokens created and after a while the Access Token times out and gets deleted by the “taskScheduler” calling “defaultOAuth2ProviderTokenService.clearExpiredTokens()”. Then we have a similar szenario like above: a Refesh Token not linked to an Approved Site via an Access Token. Is this a bug aswell?

Do we maybe add the Approved Site to Refresh Tokens aswell?

Beste Grüße / Kind regards,
Dominik Schmich

____________________________________________________

[imap://jricher@imap.exchange.mit.edu:993/fetch%3EUID%3E/Projects/MITREid%3E1960?header=quotebody&part=1.2&filename=image001.png]

Dominik Schmich
Assistant Vice President | Solution Architect

Deutsche Bank AG
COO PW&CC Technology, Strategy & Architecture
Alfred-Herrhausen-Allee 16-24, 65760 Eschborn, Germany
Tel. +49 69 910-60543
Mobile +49 1723700665
Email dominik.schmich at db.com<mailto:dominik.schmich at db.com>

---
Die Europäische Kommission hat unter http://ec.europa.eu/consumers/odr/ eine Europäische Online-Streitbeilegungsplattform (OS-Plattform) errichtet. Die OS-Plattform kann ein Verbraucher für die außergerichtliche Beilegung einer Streitigkeit aus Online-Verträgen mit einem in der EU niedergelassenen Unternehmen nutzen.

Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank finden Sie unter https://www.deutsche-bank.de/Pflichtangaben. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

The European Commission has established a European online dispute resolution platform (OS platform) under http://ec.europa.eu/consumers/odr/. The OS platform can be used by a consumer for the extra-judicial settlement of a dispute of online contracts with a provider established in the EU companies.

Please refer to https://www.db.com/disclosures for information (including mandatory corporate particulars) on selected Deutsche Bank branches and group companies registered or incorporated in the European Union. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

---
Die Europäische Kommission hat unter http://ec.europa.eu/consumers/odr/ eine Europäische Online-Streitbeilegungsplattform (OS-Plattform) errichtet. Verbraucher können die OS-Plattform für die außergerichtliche Beilegung von Streitigkeiten aus Online-Verträgen mit in der EU niedergelassenen Unternehmen nutzen.

Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank finden Sie unter https://www.deutsche-bank.de/Pflichtangaben. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

The European Commission has established a European online dispute resolution platform (OS platform) under http://ec.europa.eu/consumers/odr/. Consumers may use the OS platform to resolve disputes arising from online contracts with providers established in the EU.

Please refer to https://www.db.com/disclosures for information (including mandatory corporate particulars) on selected Deutsche Bank branches and group companies registered or incorporated in the European Union. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

---
Die Europäische Kommission hat unter http://ec.europa.eu/consumers/odr/ eine Europäische Online-Streitbeilegungsplattform (OS-Plattform) errichtet. Verbraucher können die OS-Plattform für die außergerichtliche Beilegung von Streitigkeiten aus Online-Verträgen mit in der EU niedergelassenen Unternehmen nutzen.

Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank finden Sie unter https://www.deutsche-bank.de/Pflichtangaben. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

The European Commission has established a European online dispute resolution platform (OS platform) under http://ec.europa.eu/consumers/odr/. Consumers may use the OS platform to resolve disputes arising from online contracts with providers established in the EU.

Please refer to https://www.db.com/disclosures for information (including mandatory corporate particulars) on selected Deutsche Bank branches and group companies registered or incorporated in the European Union. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170323/9186b2db/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00001.png
Type: image/png
Size: 1478 bytes
Desc: ATT00001.png
Url : http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170323/9186b2db/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00002.png
Type: image/png
Size: 56889 bytes
Desc: ATT00002.png
Url : http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170323/9186b2db/attachment-0003.png