Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

[Janak Amarasena]

Hi,

A few rewording suggestions;

*section-6.2*
Original:
The Application Server SHOULD use the OAuth 2.0 authorization code grant to
initiate a request *request *for an access token...

Suggestion:
The Application Server SHOULD use the OAuth 2.0 authorization code grant to
initiate a request for an access token.

*section-7*
Original:
Public browser-based apps needing user authorization create an
authorization request URI with the authorization code grant type per
Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being
received by the app.

Suggestion:
Public browser-based apps needing user authorization *should *create an
authorization request URI with the authorization code grant type *as *per
Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being
received by the app.

*section-8*
Original:
 can potentially continue using the stoken refresh token to obtain new
access without being detectable by the authorization server.

Suggestion:
can potentially continue using the *stolen *refresh token to obtain new
access *tokens *without being detectable by the authorization server.

Also in *section-9.6,* it is a bit hard to understand what is meant by the
below statement.
*If POSTs in particular from unsupported single-page applications* are to
be rejected as errors per authorization server security policy...


Best Regards,
Janak Amarasena

On Tue, Jul 9, 2019 at 6:43 AM Leo Tohill  wrote:

> I see now that my arguments for softening the 6.1 language are backed and
> expanded on by the last paragraph of section 5, starting with " By
> redirecting to the authorization server,..."
>
>
> On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill  wrote:
>
>>  regarding 6.1. Apps Served from a Common Domain as the Resource Server
>>
>> Isn't this recommendation neglecting some benefits  or use cases of
>> Oauth?
>>
>> * An application that doesn't collect user credentials is an app that
>> doesn't need to be audited for problems such as password leakage into log
>> files.
>> * Applications that offload authentication to a identity server can
>> delegate to that server the complexities of MFA, password recovery,and the
>> like.  Of course these CAN be done in the app, but isn't it sometimes
>> better to centralize those features in a identity server?  Especially if
>> the organization has multiple apps that require these features.
>>
>>
>> I would soften " it is likely a better decision"  to "it may be a better
>> decision".
>>
>> Leo
>>
>>
>> On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki  wrote:
>>
>>> Hi all,
>>>
>>> I've just uploaded a new version of oauth-browser-based-apps in
>>> preparation for the meeting in Montreal.
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02
>>>
>>> This draft incorporates much of the feedback I've received over the last
>>> couple months, as well as what we discussed at the last meeting in Prague.
>>>
>>> The primary change is a significant rewrite and addition of Section 6 to
>>> highlight the two common deployment patterns, a SPA with and without a
>>> dynamic backend.
>>>
>>> Please have a look and let me know what you think. I have a slot in the
>>> agenda for Montreal to present on this as well.
>>>
>>> Thanks!
>>>
>>> 
>>> Aaron Parecki
>>> aaronparecki.com
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Transaction Authorization

[Justin Richer]

I have requested time to present Transactional Authorization (the XYZ project) 
at the Montreal meeting in a couple weeks. Ahead of that, I’ve uploaded a new 
version of the spec:

https://tools.ietf.org/html/draft-richer-transactional-authz-02

Additionally, I’ve updated the writeup and examples on https://oauth.xyz/

I plan to be in Montreal for the whole week, and I’ve requested from the chairs 
that I present during the Tuesday session due to limited availability of some 
key WG members on Friday.

— Justin

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

Re: [OAUTH-WG] Refresh tokens

[George Fletcher]

For historical references only... the Google model around refresh tokens 
and the AOL model around refresh tokens were slightly different. So I 
proposed a bunch of the OIDC text around refresh tokens and offline 
access to allow for both models.


At AOL, the model was that refresh_tokens were bound to the 
authentication session by default. The only way to get an "unbound" 
refresh_token was to request the 'offline_access' scope. We restricted 
which clients could request the 'offline_access' scope and limited it 
mostly to native apps.


I'm happy to recommend errata text (as long as it's just explanatory) to 
the OIDC spec should someone have a recommendation they'd like to make:)


On 7/9/19 2:08 AM, David Waite wrote:



On Jul 8, 2019, at 8:39 PM, Aaron Parecki > wrote:


These are all very good points! I think the challenge here is 
figuring out where this kind of guidance is most appropriate.


It does seem like some of these issues are unique to a browser 
environment (particularly where the browser itself is managing the 
access and refresh tokens), so maybe it makes the most sense to 
include this guidance in the browser based app BCP?


Yes, the location is a challenge - the ???offline??? distinction is 
defined (arguably under-defined) by OpenID Connect. OAuth (on the 
other hand) does not take a stand on user authentication sessions, 
since the tokens are for delegated access.


For confidential clients, both online and offline options make sense. 
For native apps, the push is usually for long-term access or for a 
session separate from the external user agent. But for browser apps, 
you typically want to mirror user authentication.


If there are situations in which this advice is applicable in other 
scenarios in addition to browser apps, then I think it would make 
more sense to include it in the general OAuth security BCP.


The Security BCP already has some language around refresh tokens, but 
I haven't reviewed it in a while to see if all of these points might 
be already covered there.


If folks think the Browser BCP is the best place for this kind of 
thing I am definitely open to it, and I can work with David on the 
specific language to add.


- Aaron


-DW

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


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

Re: [OAUTH-WG] Refresh tokens

[George Fletcher]

I'll just add a couple more thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" 
scenario and should be used there.


2. To use a refresh token at the /token endpoint, client authentication 
is required. This is where it gets difficult for default SPAs because 
they are public clients and the only mechanism to authenticate them is 
the client_id which is itself public. For me, this is the real risk of 
exposing the refresh_token in the browser.


3. If the AS supports rotation of refresh_tokens and an attacker steals 
one and uses it, then the SPA will get an error on it's next attempt 
because it's refresh_token will now be invalid. If the refresh_tokens 
are bound to the user's authentication session, then the user can logout 
to lockout the attacker. However, that is a lot of "ifs" and still 
provides the attacker with time to leverage access via the compromised 
refresh_token.


In principle, I agree with the recommendation that SPAs shouldn't have 
refresh_tokens in the browser. If it's not possible to easily refresh 
the access token via a hidden iframe (becoming more difficult with all 
the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to 
use a simple server component such that the backend for the SPA can use 
authorization_code flow and protect a client_secret.


Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:


On Jul 8, 2019, at 7:10 PM, Leo Tohill > wrote:

Re 8. Refresh Tokens

 "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially
?? ??continue using the stolen refresh token to obtain new access without
?? ??being detectable by the authorization server.?? "

(first, note the typo "stoken".)

Is it always "higher risk"??? I could even argue that leakage of a 
refresh token is lower risk. As a bearer document, a leaked access 
token allows access to resources until it expires.?? A leaked refresh 
token, to be useful,?? requires an exchange with the AS, and the AS 
would have the opportunity to check whether the refresh token is 
still valid (has not been revoked). (of course revocation might NOT 
have happened, but then again, it might have.)


I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (by 
policy) to an authentication session lifetime. It is far easier to 
picture refresh tokens which are not attached to an authentication 
session (sometimes called ???offline??? access) being inappropriate for a 
browser-based app, which is nearly always a client that the resource 
owner is interacting with.


Variants that may want offline tokens are less easy to imagine - 
perhaps browser extensions?


I believe the language currently there is due to AS implementations 
predominantly treating refresh tokens as being for offline access, and 
access token lifetime being short enough to not outlast an 
authentication session.


Furthermore, since the access token is transmitted to other servers, 
the risk of exposure is greater, due to possible vulnerabilities in 
those called systems (e.g., logs).?? Isn't this the reason that we 
have refresh tokens? Don't refresh tokens exist because access tokens 
should have short TTL, because they are widely distributed?


Yes. Once you acknowledge the existence of ???online??? refresh tokens, 
they become a strong security component:


- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to 
invalidate access without needing to resort to token 
introspection/revocation
- Token refresh can theoretically be used to represent other policy 
changes by both the client (creating tokens targeting a new resource 
server or with reduced scopes) and server (changing entitlements and 
attributes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security 
BCP. A exfiltrated refresh token will result in either the attacker or 
the user losing access on the next refresh, and a double refresh is a 
detectable security event by the AS.


"Additionally, browser-based applications provide many attack vectors 
by which a refresh token can be leaked."


The risks of leaking a refresh token from the browser are identical 
to the risks of leaking an access token, right??? This sentence could 
be changed to "... by which /a token/ can be leaked."


A refresh token is "higher risk" because its TTL is usually greater 
than the access token's TTL.?? But if our advice here leads to people 
using longer-lived access tokens (because of the problems with 
getting a new access token without involving the user), then the 
advice will be counter productive. The longer life gives more time 
for the usefulness of a browser-side theft, and more time for the 
usefulness of a server-side theft.


Which scenario is safer?
A) using an 

[OAUTH-WG] historical note regarding use of url fragment in OAuth for Browser-Based Apps draft -02

[Leo Tohill]

re:

9.8.7 
.
Historic Note

   Historically, the Implicit flow provided an advantage to single-page
   apps since JavaScript could always arbitrarily read and manipulate
   the fragment portion of the URL without triggering a page reload.
   Now with the Session History API (described in "Session history and
   navigation" of [HTML
]),
browsers have a mechanism to modify the path
   component of the URL without triggering a page reload, so this
   overloaded use of the fragment portion is no longer needed.


Does this historical note mean to indicate that if the implicit flow were
designed today, it could use path instead of fragment to carry the token?

Doesn't this overlook the important aspect that fragments are not sent to
the server?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh tokens

[David Waite]

> On Jul 8, 2019, at 8:39 PM, Aaron Parecki  wrote:
> 
> These are all very good points! I think the challenge here is figuring out 
> where this kind of guidance is most appropriate.
> 
> It does seem like some of these issues are unique to a browser environment 
> (particularly where the browser itself is managing the access and refresh 
> tokens), so maybe it makes the most sense to include this guidance in the 
> browser based app BCP?

Yes, the location is a challenge - the “offline” distinction is defined 
(arguably under-defined) by OpenID Connect. OAuth (on the other hand) does not 
take a stand on user authentication sessions, since the tokens are for 
delegated access.

For confidential clients, both online and offline options make sense. For 
native apps, the push is usually for long-term access or for a session separate 
from the external user agent. But for browser apps, you typically want to 
mirror user authentication.
 
> If there are situations in which this advice is applicable in other scenarios 
> in addition to browser apps, then I think it would make more sense to include 
> it in the general OAuth security BCP.
> 
> The Security BCP already has some language around refresh tokens, but I 
> haven't reviewed it in a while to see if all of these points might be already 
> covered there.
> 
> If folks think the Browser BCP is the best place for this kind of thing I am 
> definitely open to it, and I can work with David on the specific language to 
> add.
> 
> - Aaron

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