Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Tomek Stojecki <[e-mail]>]

 >> The AS can bind the lifetime of the refresh tokens to the session lifetime, i.e. automatically revoke it on logout. 

> Yea, I saw your other email asking about refresh token revocation relating to session management. Obviously for certain clients, this won't make sense, but for implicit/browser-based ones it's a nice feature to have.
I agree that this can be useful, however with where we are today, is this supported by auth servers such that it can distinguish offline from renewable-online clients and only revoke the latter when logging out? 
> The alternative, as you mentioned, is to not issue refresh tokens and do token renewal the "same old way" via iframe with prompt=none, while still using code flow.

Going from Implicit to Code deals with the problem of sending RT in the URL, which I agree is a plus. Is there anything else in a way of an improvement? I still am not comfortable enough with the idea of releasing RTs to the browser clients where it can't be encrypted, prone to xss, etc... 

-Tomek
    On Thursday, November 15, 2018, 11:01:37 PM GMT+1, Brock Allen <[e-mail]> wrote:  
 
   > It still lacks the ability to issue sender constraint access tokens.
So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)? Resource servers don't know the flow the clients might use, especially if/when they have many clients.
> The AS can bind the lifetime of the refresh tokens to the session lifetime, i.e. automatically revoke it on logout. 

Yea, I saw your other email asking about refresh token revocation relating to session management. Obviously for certain clients, this won't make sense, but for implicit/browser-based ones it's a nice feature to have.
The alternative, as you mentioned, is to not issue refresh tokens and do token renewal the "same old way" via iframe with prompt=none, while still using code flow.
> The only potential „baby step“ I would see is to move towards „token id_token“. Since this requires signature/at_hash checks etc. I doubt this is really easier than moving to code and exchange the code for an access token. What’s your opinion?
Even since OIDC arrived, this is the only flow I use for JS/browser-based clients (anything less has always seemed so obviously inferior). So for me and my customers, all browser-based clients I am involved in are already there. Perhaps this is the reason for all of my questions/comments about the recent BCP doc. Given "id_token token", CSP, and using the browser history API to wipe the access token from browser history, we already have a decent set of tools to mitigate attacks. As I already conceded, the only remaining issue (IMO) is the short window of time the access token is in the URL.
Given that it seems to me that OIDC and OAuth2 are typically used together (at least when a user is involved with authentication), I always wonder why the OAuth and OIDC WGs are separate. Given that so much effort of the two sets of specs overlap, it seems odd to keep adding onto the OAuth specs and ignoring the added features that OIDC provides. I don't mean to derail this thread, or step on any political toes, so apologies in advance.

-Brock
 _______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth