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

[Justin Richer]

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
>
> ____________________________________________________
>
>
>
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170313/5d107ec1/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1478 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170313/5d107ec1/attachment.png