Hi Brock,

> Am 15.11.2018 um 23:01 schrieb Brock Allen <brockal...@gmail.com>:
> 
> > 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)?

Sure. That’s why the Security BCP recommends use of TLS-based methods for 
sender constraining access tokens 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). 
Token Binding for OAuth 
(https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are 
the options available. 


> Resource servers don't know the flow the clients might use, especially 
> if/when they have many clients.

They don’t need to. All they need to know is how to determine whether the 
sender of the token is the legit client. This is achieved by comparing the hash 
of the token binding id or the cert of the client conveyed in the access token 
with the respective data from the TLS handshake. 

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

yes. 

Have you ever experienced issues with the latter approach and the browser’s 3rd 
party cookie policy?

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

There are two angles to approach access token leakage and replay from two 
angles, (a) preventing leakage (that’s what you can do with the browser history 
API, TLS, ...) or (b) detecting replay (that’s what one can do with sender 
constraint access tokens). 

The focus of OAuth/OIDC was on (a) but experiences have shown this is of 
limited effectivity, especially in dynamic/open scenarios, which we are seeing 
increasingly due to open banking, eHealth, eID, …. So sealing the problem from 
both ends seems reasonable.  
 
> 
> 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.

No problem. As already stated, OIDC, esp. FAPI, and OAuth need to be aligned on 
that point. 

Thanks for the insights you shared. We will be publishing another revision of 
the OAuth Security BCP soon, which also adds recommendation and justification 
based on our discussions. 

kind regards, 
Torsten. 

> 
> 
> -Brock
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to