My intent wasn’t to suggest that tokens *must* be origin constrained, just to
point out if you are using TLS-based sender constrained tokens then you may
also want to consider that aspect.
In some cases you may be comfortable that protections against in-browser token
theft are adequate without
Agreed. Consider also service account flows such as the JWT-bearer approach
used by Google:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#authorizingrequests
It’s not clear there is any session at all in these cases. (Although I don’t
think there is a refresh token in th
In some cases, the resource server will need to support CORS in order to
support SPA clients that are on different origins. In this case, the resource
server must optimistically allow the CORS request to be made, then validate
that the request origin is appropriate for the access token provided
I think we need to be very careful about prescribing behavior around refresh
token lifetime, and setting expectations for what degree of consistency is
attainable. Considering the terms "session", "authenticated session",
"offline", "expiration", "termination", and "log out" can mean different t
Inline:
2018年11月29日(木) 0:03 Torsten Lodderstedt :
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with „token“ (only). It would allow
> „token“ to be used if the token would sender constrained. This completely
> ignores th
On Wed, Nov 28, 2018 at 2:51 PM n-sakimura wrote:
> That works.
>
> In fact, I would further go and say MUST NOT but that probably is too much
> for a security consideration.
>
>
Personally I think it's fine for a MUST NOT to appear in a security
consideration section of a BCP. If you break it, t
> Am 28.11.2018 um 23:50 schrieb n-sakimura :
>
> That works.
Good!
I just realized this text has an issue with „token“ (only). It would allow
„token“ to be used if the token would sender constrained. This completely
ignores the fact implicit also shall be abandoned because of its vulnerabili
That works.
In fact, I would further go and say MUST NOT but that probably is too much for
a security consideration.
Best,
Nat
Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げま
Hi Nat,
> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>
> I would support
>
> 1) clearly defining Implicit as the flow that returns access token from the
> authorization endpoint ( some people confuses implicit as the flow that
> returns ID Token in the front channel)
That’s the current text
I would support
1) clearly defining Implicit as the flow that returns access token from the
authorization endpoint ( some people confuses implicit as the flow that returns
ID Token in the front channel)
2) Banning the returning of the access token that are not sender constrained
from the autho
+1
While there are various mechanisms to alleviate some of the issues of
implicit, I don't think we can recommend specifics, and there may be future
ones in the future. I think we all agree that implicit without any
mitigation is problematic.
How about we recommend against using implicit alone?
Thank you, Alissa, for the review. Please see below for inline
comments/responses and note that this is also my response to your last
message on the related thread at
https://mailarchive.ietf.org/arch/msg/oauth/MKqEIsb8TJCFUNl3vF-bB38nWv4
On Tue, Nov 20, 2018 at 12:50 PM Alissa Cooper wrote:
>
Apologies, I may be speaking out of turn by not fully understanding the use
cases that this thread may be focused on. I’m interpreting the conclusions you
are proposing as general recommendations rather than addressing a specific case.
IMO the biggest general value of refresh is a periodic proof
> Am 28.11.2018 um 16:53 schrieb George Fletcher :
>
> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>> Hi George,
>>
>>> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>>>
>>> Thanks for the additional section on refresh_tokens. Some additional
>>> recommendations...
>>>
>>> 1. By defau
Apologies, I missed the *issued* in "issued a shared secret", just reading
"shared secret" alone is the exact opposite of a per-instance secret. The
rest is clear and as you say it brings the benefit of the secret never
being sent over the wire (except during the initial registration via TLS).
Bes
It's "confidential" in that the shared secret is unique to that app
instance registration (as Dennis described in his response). If an
attacker gets my phone and compromises the data stored on my device,
they only get the secret for my device. This is no different than a
server side client havi
Hi George,
#2 doesn't seem confidential, it's still a secret shared amongst
installations and anyone reverse engineering the apk, extracting the
secret, can form the client_secret_jwt client_assertion with it just fine.
Best,
Filip
On Wed, Nov 28, 2018 at 4:48 PM George Fletcher wrote:
> In ad
On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
Hi George,
Am 20.11.2018 um 23:38 schrieb George Fletcher :
Thanks for the additional section on refresh_tokens. Some additional
recommendations...
1. By default refresh_tokens are bound to the user's authenticated session.
When the authentica
In addition, a few additional patterns are enabled...
1. The native app can generate a public/private key pair and then use
private_secret_jwt as the client credential validation method via the
client credentials flow (defined in OpenID Connect).
2. Maybe more simply, if the native app is iss
Thank you for the review, Adam. I do sincerely hope that your time with the
document didn't drive you to drink (too much anyway). Please see below for
inline comments/responses.
On Tue, Nov 20, 2018 at 4:39 PM Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-i
ITP cookie blocking doesn't kick in until a site is classified as a tracker
- if it's a fresh browser, everything will work. That's why you need to
test with the ITP debug tools to set your site as prevalent.
On Wed, Nov 28, 2018 at 3:00 AM Thomas Broyer wrote:
> Yes, that was with the default c
Yes, that was with the default cookie policy (on a coworker's macbook, and
he doesn't use safari as his main browser)
On Wed, Nov 28, 2018 at 11:20 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> with the default cookie policy?
>
> > Am 23.11.2018 um 14:34 schrieb Thomas Broyer :
> >
>
with the default cookie policy?
> Am 23.11.2018 um 14:34 schrieb Thomas Broyer :
>
> Just tested my OpenID Connect Session Management implementation with Safari
> 12.0.1 and it works like a charm.
>
> On Thu, Nov 22, 2018 at 8:09 PM George Fletcher
> wrote:
> My understanding is that cookies
Hi George,
> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>
> Thanks for the additional section on refresh_tokens. Some additional
> recommendations...
>
> 1. By default refresh_tokens are bound to the user's authenticated session.
> When the authenticated session expires or is terminated
Hi Aaron,
> Am 20.11.2018 um 21:37 schrieb Aaron Parecki :
>
> The new section on refresh tokens is great! I have a couple
> questions/comments about some of the details.
>
> Authorization servers may revoke refresh tokens automatically in case
> of a security event, such as:
> o logout at the
25 matches
Mail list logo
