[mitreid-connect] Revoke Consent keeps Refresh Tokens [I]
Justin Richer
jricher at mit.edu
Mon Mar 20 08:26:30 EDT 2017
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>; mitreid-connect
> <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/
> <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170320/3329eb2a/attachment-0001.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/20170320/3329eb2a/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 56889 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20170320/3329eb2a/attachment-0003.png
More information about the mitreid-connect
mailing list