Hi Brock, > Am 15.11.2018 um 15:01 schrieb Brock Allen <brockal...@gmail.com>: > > > Helps to prevent leakage, not injection in the authorization response. > > So then wording and its motivation could get updated to correctly reflect > that. > > >> "OAuth 2.0 provides no mechanism for a client to verify that an access > >> token was issued to it, which could lead to misuse and possible > >> impersonation attacks if a malicious party hands off an access token it > >> retrieved through some other means to the client." > >> > >> Sure, but OIDC does provide a mitigation for this (even with implicit). > > > >This is about token replay detection at the RS. What mitigation does OIDC > >provide here? > > The wording doesn't go with that, then. My point about OIDC is that with the > at_hash in the id_token provides a mitigation so the client can verify that > the access token was issued to it.
Understand, you are referring to the token injection prevention provided by „token id_token“ or „code token id_token“.. It still lacks the ability to issue sender constraint access tokens. So if you wanna take the risk associated with bearer tokens you can use it. The Security BCP recommends to use sender constraint access tokens, so we cannot recommend response types not supporting this pattern. > > > The implicit grant was not equipped with the ability to issue refresh > > tokens simply because the working group didn’t want them to end up in the > > browser history, leak through open redirectors etc. This is different with > > code since tokens travel directly through a TLS protected connection. > > Well, if limiting the access token renewal to the user's session lifetime > wasn't a conscious design goal, it's a very interesting side effect which > does limit the potential of an attacker. That’s true. Note that the effectiveness of limitation depends on the lifetime of the issued access tokens. The AS can bind the lifetime of the refresh tokens to the session lifetime, i.e. automatically revoke it on logout. In my opinion, whether this is the most appropriate choice largely depends on what the client uses the token for. If the client effectively relies on the AS (OP) to login the user and obtain user data that makes sense. If the client has an independent login and uses the tokens to access resources (e.g. contacts), the session with the AS does not have a real meaning with respect to this client. Potentially the client even stores the refresh token in a backend with the user account. > > > First of all the AS decides whether it issues refresh tokens or not. Having > > the ability does not mean the AS must do it. If you feel it’s safer to not > > do it. Fine. > > Sure, and this should be mentioned then somewhere (either in the threats doc > or in this proposed best practice doc). Not all end developers using these > protocols fully understand the ramifications. @Aaron: I suggest this goes to the SPA BCP since this is client specific. > > > It’s still possible to refresh your access tokens the way you mentioned > > above by sending another authorization request to the AS. > > This also could be added as a proposal for an alternative to renewing tokens. > It provides more awareness to folks, and aids in a potential best practice > depending on the requirements of the consuming app. I agree. > > > But let’s assume for a moment the AS, based on its risk assessment, decides > > to issue refresh tokens. Can you please explain how an attacker will get > > access to this tokens? Especially what the expected strength of the > > attacker would need to be? > > I don't have a profile of an attack. But I'm assuming it's no different than > anything in the past we've been trying to defend against when we considered > the potential for an access token to be exfiltrated. So my point is that an > access token will expire so an attacker would then have to go back and > re-attack the app to get a new access token to continue to have access to the > user's resource. But now with refresh tokens in the picture, the attacker > would have both and then not need to go back to the app to continue to have > access to the user's resource. Largely depends on the refresh token protection. I case of public clients I would always recommend to rotation refresh tokens with every refresh. This renders the old refresh tokens useless. If the attacker happens to be at the lucky end and conducts the first refresh, the AS should be able to detect the replay when the legit user tries to refresh. It then shall revoke the active (in possession of the attacker) refresh token as well. I will add this to the Security BCP. > > > I would also like to understand how a refresh token is any different from a > > long living cookie in the browser and what you think is the big difference > > to mobile apps when it comes to refresh token handling. > > To use the cookie, the app must be active, and the attacker must be attacking > the app itself. > > Maybe a different way to say it is that an attacker must only compromise the > app once to have long lived access, whereas without refresh tokens the > attacker can attack the app once, but the once the comprised access token is > expired they would have to re-attack the app to get another access token. > Refresh tokens means they only have to get in once to the app, then they no > longer have to go back to the source. Maybe there's a better way to convey > what I'm trying to say… I think I understand. Refresh tokens can be used outside of the user agent. Token rotation and expiration would be potential mitigations, token binding too. > > Also, I guess my question/comment about providing guidance for existing > implicit flow clients is not up for discussion? Again, my reasoning is that > it's a hard sell to always say there's exactly one right way to do something. > And since so many clients have been built based on implicit flow that might > not be able to change quickly to a new flow, perhaps there are "baby steps" > that can be suggested to help them improve their security. 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? kind regards, Torsten. > > -Brock >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
