[mitreid-connect] Revoke Consent keeps Refresh Tokens [I]
Justin Richer
jricher at mit.edu
Fri Mar 24 08:26:34 EDT 2017
You don't need that information to build out a UI though -- just revoke
all tokens associated with a given user and client combination, and also
the approved site (which is a stored grant). Everything should cascade
fine if you do:
- All approved sites
- All refresh tokens
- All remaining access tokens (this includes ID tokens in versions
earlier than 1.3)
All the API calls and service layer hooks are already there for this
action. The UI can easily hide the fact that it's doing these multiple
operations and give the user a button.
-- Justin
On 3/23/2017 1:11 PM, Dominik Schmich wrote:
> 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>; 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.
>
>
>
> ---
> 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/20170324/f6782878/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/20170324/f6782878/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/20170324/f6782878/attachment-0003.png
More information about the mitreid-connect
mailing list