I agree with Vittorio, Dominick et al.
> I disagree.
> Existing deployments that have not mitigated against the concerns with
> implicit should be ripped up and updated.
Yes, just like future deployments that will not mitigate against the concerns
of code in the browser should be a concern.
t feasible (can't authenticate the client,
confidentiality in storage? - not sure how to read that in the context of a
browser)
On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt
wrote:
Hi Tomek,
> Am 04.12.2018 um 09:50 schrieb Tomek Stojecki
> :
>
trying to say is that I think context is important here. So when you
point out these best practices, some of them will get people confused as far as
what it means in the browser based app scenario. Maybe it is just me :)
>
> On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lod
> FWIW, in addition, those can be used together -- sliding & absolute.
Azure AD does both at this point. They used to do 90 days absolute, now it is a
sliding, 72 hours by default I believe.
Good discussion overall, would this be a good summary for the type of a client
the spec is for:
SHOUL
I agree that 6.1 takes too broad of a swipe, but I'd say with same-site cookies
and (sadly) without token-binding, the suggestion to use cookie based session
following oauth/oidc auth is a good one and should be incorporated perhaps in
6.2?
Leo sums it up well here:
> We need to be clear on the
)
Finally, how is the AT going to be refreshed? Are we allowing for long lived RT
in the browser? I see that the document mentions CSP in 7.7, but doesn't the
same apply to securing AT with Implicit?
Regrads,
Tomek Stojecki
On Tuesday, November 6, 2018, 10:55:40 AM GMT+1, Hannes Tschofenig
>> 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 impli
